Clear documentation of SharePoint rest API 2.1 to get the image thumbnails.
Last week, overnight, MS replaced all the thumbnails urls (PictureThumbnailURL managed property) that the search api returns from 'getpreview.ashx' to '{tenant-url}/_api/v2.1/drives/{drive-id}/items/{item-id}/thumbnails/0/c400x99999/content?preferNoRedirect=true' urls.
This happened in all tenants, not only on "target release" tenants, so no time to react in my clients.
All my search-driven webparts started to display a very small image, as they were expecting the old 'getpreview.ashx' URL.
I am trying to figure out how can I get the thumbnails based in this article https://docs.microsoft.com/en-us/graph/api/driveitem-list-thumbnails?view=graph-rest-1.0&tabs=http#size-options
My findings so far (test with an image 1800x1012):
The OOTB News webpart also fails to bring some images when it is in a carousel mode (c1600x99999)
I would expect that by doing a GET to {tenant-url}/_api/v2.1/drives/{drive-id}/items/{item-id}/thumbnails I could see all the existing thumbnails but I get an 'Item not found' message.
I would expect that by doing a GET to {tenant-url}/_api/v2.1/drives/{drive-id}/items/{item-id}/content?preferNoRedirect=true I could get the image with the original size.
How to know which custom sizes work and which don't?
Any clue what is the preferNoRedirect=true parameter for?
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
Facing similar scenario: I have a SPFx web part using search API to display news posts with image from the news modern page using "PictureThumbnailURL" managed property which has started to return image url as https:///_api/v2.1/drives/../items/.../thumbnails/0/c400x99999/content?preferNoRedirect=true instead of getpreview.ashx.
It is observed that some of the news image are not displayed with such PictureThumbnailURL; when accessed such url in seperate browser it returns Item not found error.

Any updates on this?
Not familiar with this... trying to understand the root of the issue to bring the right person into the thread... is this a Search API question on how it's generating thumbnails?
Thank you for taking interest in solving this issue.
It is not a Search API question. I would say it is a SharePoint REST API v2.1 / OneDrive bug.
Also, if it's easier/faster, it can be treated as an OOTB webpart bug.
See in the attached image that the OOTB News webpart is not loading a 1600x900px image thumbnail for the carousel layout (c1600x99999) but it is working for other layouts (c400x99999 and c960x99999). The thumbnail of the 1280x720px image is not showing in any layout.

Unfortunately, we can't do anything about OOTB features here in this forum... those have to be handled through your tenant's admin center & support tickets. This is only a forum for developer issues.
I opened a Premier support ticket (Convergys Corporation) about this in November but there is not any progress at all in MS solving this issue so far. @Chaitra1006 did you have more luck?
My experience dealing with this MS support ticket is very frustrating and I think they are a very unprofessional team.
Is there any other alternative to MS support tickets? I think if we open support tickets instead of github issues (or whatever) the community cannot beneficiate from our issues/fixes discoveries.
Finally, I discovered that there is a Manage Property called URLAnchor that contains the image thumbnail URL using getpreview.ashx (as PictureThumbnailURL used to be). Any idea if is it safe to use the URLAnchor Manage Property to get the thumbnail? This managed property doesn't appear in the admin UI.
@wobba do you have a suggestion?
As for the REST endpoint for thumbnails and inconsistencies in what you get maybe @JeremyKelley can help. As for search and thumbnails, I know there is internal things happening here, not exposed publicly. I'll try to figure out what we return and how it can be used.
@Rafaelki in your original question you state you are getting small images. The URL points to having a width of 400px, is that small? Or is the returned image smaller than 400px wide? It's also called a thumbnail API ;)
The getpreview.ashx handler is an internal handler and is going away, so you should not take a dependency on this. As for issues with sizes using the thumbnail API, these are being tracked internally and should be rolled out this month is what I've been told.
Is it ok if I close this for now, and you can re-open if you don't see any change on the Graph thumbnail API within the month or so?
Hello @wobba, thank you very much for looking into this and for splitting the problem between Search and REST.
400px is perfect when it works (see screenshot in the @Chaitra1006 comment).
I think Search does the right thing with PictureThumbnailURL; it provides a _base URL_ that a developer can easily change to get other thumbnail sizes:
My comment about the small images is because one of my webparts is a full width carousel (OOTB News cannot be set in a full with section) and my code was concatenating the "resolution" querystring to the PictureThumbnailURL and obviously it stopped working as planned.
@andrewconnell, maybe I am doing the wrong thing about manipulating PictureThumbnailURL and there is an easier and safer way to get different resolutions of the PictureThumbnailURL?
So from the Search perspective, my only issue was that this change was not correctly notified and the change affected to "standard release" tenants at the same time that "target release" tenants so we didn't have time to react in our clients. No to mention that the change was made from something stable to a buggy API.
About the thumbnail API, thank you for the estimated time to resolution. That is very useful, at least we have some information to tell our clients.
It is ok for me if you close this issue for now :)
I opened a Premier support ticket (Convergys Corporation) about this in November but there is not any progress at all in MS solving this issue so far. @Chaitra1006 did you have more luck?
My experience dealing with this MS support ticket is very frustrating and I think they are a very unprofessional team.
Is there any other alternative to MS support tickets? I think if we open support tickets instead of github issues (or whatever) the community cannot beneficiate from our issues/fixes discoveries.Finally, I discovered that there is a Manage Property called URLAnchor that contains the image thumbnail URL using getpreview.ashx (as PictureThumbnailURL used to be). Any idea if is it safe to use the URLAnchor Manage Property to get the thumbnail? This managed property doesn't appear in the admin UI.
No, I was experiencing the same with the MS ticket.
Using getpreview.ashx was never officially documented, although it worked ;) Manipulating or using the new documented thumbnail API is definitely the way forward, and any issues with that API should be tracked indeed.
Appending the preferNoRedirect=true parameter seems to ignore the actual size you specify, showing a more generic cached version. This parameter tries to load the thumbnail from the domain you are calling from instead of redirecting to a CDN - an internal parameter which I don't know the details of, but figured out from testing just now.
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues
For reference I blogged an option at https://www.techmikael.com/2020/01/retrieving-thumbnailspreviews-for.html on how to work with thumbnails.
Most helpful comment
Hello @wobba, thank you very much for looking into this and for splitting the problem between Search and REST.
400px is perfect when it works (see screenshot in the @Chaitra1006 comment).
I think Search does the right thing with PictureThumbnailURL; it provides a _base URL_ that a developer can easily change to get other thumbnail sizes:
My comment about the small images is because one of my webparts is a full width carousel (OOTB News cannot be set in a full with section) and my code was concatenating the "resolution" querystring to the PictureThumbnailURL and obviously it stopped working as planned.
@andrewconnell, maybe I am doing the wrong thing about manipulating PictureThumbnailURL and there is an easier and safer way to get different resolutions of the PictureThumbnailURL?
So from the Search perspective, my only issue was that this change was not correctly notified and the change affected to "standard release" tenants at the same time that "target release" tenants so we didn't have time to react in our clients. No to mention that the change was made from something stable to a buggy API.
About the thumbnail API, thank you for the estimated time to resolution. That is very useful, at least we have some information to tell our clients.
It is ok for me if you close this issue for now :)