YouTube thumbnails.set now allows 50MB: what to upload from Sume

YouTube's Data API revision history lists a September 14, 2026 change: the thumbnails.set maximum file size went from 2MB to 50MB. The method's reference page lists image/jpeg and image/png, so a jpeg or png still from Sume's video-frames route is an accepted type; the 50MB ceiling is YouTube's, and Sume's docs state no file size for a still.

What exactly changed on YouTube's side?

Only the upload ceiling is quoted here. The reference page does not list pixel dimensions or an aspect ratio, so this post makes no claim about either.

The rows below are copied from the two YouTube pages.

How do I get a still from a Sume clip?

POST /v1/video-frames takes one media.sume.com clip plus at[] (1 to 24 times in seconds) and returns durable image artifacts. Submit is always 202, so poll GET /v1/video-frames/:id until resource_status is ready, then read frames[{t,url,width,height}]. Send an Idempotency-Key so a retry does not queue a second extract.

curl -X POST https://api.sume.com/v1/video-frames \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: thumb-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/clip.mp4",
    "at": [1, 4, 7],
    "format": "png"
  }'

curl https://api.sume.com/v1/video-frames/$REQUEST_ID \
  -H "Authorization: Bearer $SUME_API_KEY"

Do I still need to shrink the image?

With max_edge omitted, frames keep the source frame size, so the still is as large as the clip. max_edge accepts 16 to 2160 if you want a long-edge clamp. Sume's docs give no way to set a target file size or a quality value, and requests carrying encoder fields are refused as ffmpeg_fields_rejected.

Because the file size of a frame is not documented, check the artifact's size on your side before you call thumbnails.set.

What does this not do?

Sume does not call YouTube for you: you download the artifact and send it to thumbnails.set yourself. The video-frames route is unbilled and takes sources up to 300 seconds; a longer clip is refused as duration_out_of_range, so cut it first with https://docs.sume.com/models/video-trim. Re-read YouTube's page before you ship, since limits move.

What is a sensible workflow?

Treat the size limit as a guard rail and the frame choice as the real decision. A short checklist keeps the handoff between Sume and YouTube predictable, and each step below uses only fields the two docs pages show.

• Import the clip to media.sume.com first with POST /v1/media-imports; the frames route refuses off-host URLs at admit.
• Submit video-frames with three to six candidate times and format: "png" if you want lossless inspection, or leave the jpeg default.
• Poll until resource_status is ready, open each frames[].url, and pick the still that reads clearly at small size.
• Download the artifact and send it to thumbnails.set in your own YouTube-authorized call, with a type from the accepted list.
• Log the artifact id next to the YouTube video id so you can find the source of any thumbnail later.

Where does the old 2MB habit still matter?

Anything you built around the old 2MB limit, such as a compression step, is now a choice rather than a requirement, according to the revision note. Keep it if your own pipeline benefits from small files; drop it if it was only there for the limit. Sume's route never asked for that step, because it does not expose encoder settings at all.