Video & subtitles · YouTube Thumbnail Downloader & Metadata Viewer
How a browser saves a cross-origin image: fetch, Blob URLs and download
· How it works
youtube javascript cors
Saving an image from another domain is harder than a link with a download attribute. This post explains why the attribute is ignored for cross-origin URLs, how fetch and Blob URLs solve it and what CORS has to do with it.
The download attribute opened the image instead of saving it — the cross-origin catch
An anchor pointed at a different origin may navigate to an image instead of honoring a desired filename. A dependable downloader needs readable bytes under browser cross-origin rules, not merely a download attribute on a remote URL. The visible test is straightforward: saving a verified JPEG should create the ToolAcre filename without adding another i.ytimg.com request.
ToolAcre already fetches each JPEG candidate to determine whether it is real. Keeping the successful Blob means the later download can use those same bytes instead of issuing a second network request. That reuse keeps the saved file identical to the image whose dimensions and placeholder status were inspected moments earlier.
Why browsers ignore download for other origins — a security decision and its consequences
Browsers constrain cross-origin downloads because a page should not silently rename and save arbitrary remote resources. Behavior depends on the remote response and origin relationship, so a simple link is not a universal file-saving API. The `download` attribute alone cannot guarantee that a remote YouTube image will be saved under the requested local name.
The safer design is explicit: request a disclosed public image, verify the response, and construct a browser-managed object URL only for data the page was allowed to read. If CORS blocks access, JavaScript has no Blob to validate or save, even though navigating directly to the image address may still display it in a tab.
The fetch-and-Blob route — fetching the image bytes, wrapping them in a Blob and creating a same-origin blob: URL
For JPEG, probeThumbnail performs an anonymous CORS GET, converts a successful response to a Blob and decodes dimensions. A usable Blob is retained on the result, while placeholders are discarded so they cannot masquerade as downloads. The download button therefore represents verified bytes in memory, not confidence inferred from a filename or HTTP 200 alone.
An object URL can then represent that in-memory Blob for a local save action. This does not make the original fetch local; Google supplied the bytes directly to the browser after Fetch. The `blob:` address is a temporary browser handle for that response body, not a mirror hosted by ToolAcre or a newly granted right to the source image.
CORS allows JPEG fetch-and-Blob downloads; WebP remains link-only
The outline implied CORS was one generic gate, but shipped behavior is format-specific. JPEG fetch-and-Blob download works; the /vi_webp/ path is served without the required cross-origin header, so ToolAcre provides WebP as a link only. A reviewer should test the two path families separately instead of generalizing the JPEG response headers to every thumbnail format.
That limitation is not repaired by changing JavaScript or retrying through ToolAcre, because no ToolAcre proxy exists. A blocker, offline connection or corporate proxy can also stop either remote resource. Link-only WebP access accurately reflects what the remote server permits the page to do: point at the file, but not read its bytes for repackaging.
Naming the saved file — why a downloader should name it by video ID and size so files stay identifiable
Downloaded JPEG names use youtube-VIDEO_ID-VARIANT.jpg. Both the identifier and variant come from validated alphabets, preventing path separators or arbitrary control characters from entering the suggested filename. Saving `maxresdefault` and `hq2` from one lookup should therefore produce distinct, predictable names that can be matched back to their result rows.
A descriptive filename preserves provenance when several sizes sit in one folder. It also avoids pretending the metadata title is a safe filesystem name, since titles can contain punctuation and can change independently. The immutable ID identifies the video reference, while the variant suffix explains which published image candidate supplied the bytes.
Worked example: saving two thumbnail sizes for one video — the sequence of requests and the files that result
Fetch one public video and choose two available JPEG variants. Each was requested once during probing, decoded to prove dimensions and retained as a Blob; clicking save should reuse that result and produce two clearly named files. With DevTools open, the absence of a second image request confirms that the save came from the retained response rather than a fresh remote download.
If one candidate returns HTTP 200 as a 120×90 placeholder, the tool marks it missing and stores no downloadable Blob. A 404, other error or undecodable response is likewise reported rather than saved. Disabling the save action for these rows prevents a generic placeholder or error payload from entering an asset folder under a convincing variant name.
What this does not cover — batch downloads across many videos, and hosts that block cross-origin reads
There is no batch mode across many videos and no bypass for hosts that forbid cross-origin reading. The product handles one video at a time and restricts itself to the two disclosed Google services. Each retained Blob belongs to the current result set, so it should not be treated as a durable cache for later videos or future versions of the same thumbnail.
It also does not retrieve video or audio, and private, deleted or age-restricted records remain unavailable. A public file-saving mechanism cannot expand access rights or manufacture an absent thumbnail. Blob creation begins only after readable image bytes arrive, so it offers no route around a denied response or an unpublished variant.
JPEG fetch, Blob reuse and download—with WebP kept as a link
Before Fetch, URL parsing is local. Afterwards, each JPEG probe and the canonical oEmbed request goes straight from the browser with credentials omitted, no referrer, no-store and followed redirects; Google sees the Origin header. Date important downloads independently, because neither the object URL nor the predictable source path preserves an earlier thumbnail revision.
The result is deliberately asymmetric: verified JPEG bytes can become Blob downloads, while five WebP poster URLs remain external links because their responses lack CORS permission. The interface should preserve that honest boundary. Users can open or copy a WebP address, but ToolAcre cannot promise a renamed local WebP file from bytes the browser forbids it to read.