Video & subtitles · YouTube Thumbnail Downloader & Metadata Viewer
Public data only: what a YouTube metadata viewer will and will not show
· Why it matters
youtube metadata privacy
ToolAcre documents what each tool will not do. This post lays out the boundary for the metadata viewer: the public title, channel and embed details it shows, the things it deliberately does not fetch and why that boundary is the right one.
A viewer, not a scraper — setting expectations before you paste a link
A public metadata viewer answers one bounded question: what thumbnail assets and structured facts can a signed-out browser obtain for this validated video reference now? It does not crawl the watch page, execute its scripts, enumerate related videos or imitate a general YouTube research API. Starting with that narrow question prevents a compact utility from being mistaken for an account-aware data source or a complete historical record.
The boundary also makes results auditable. Every displayed value comes either from a known thumbnail candidate or from the normalized oEmbed response, not from guessing at page markup. A reviewer can trace a title to author-supplied JSON, a dimension to decoded image bytes, and a generated link to the validated eleven-character ID. Repeated lookups can then compare like with like while acknowledging that public responses may change.
What is public by design — the title, channel and embed details YouTube publishes for every public video
Public in this tool means served to an anonymous request without credentials. The scope includes JPEG thumbnail candidates, five WebP poster links, and normalized oEmbed fields for title, channel, channel URL, thumbnail URL and dimensions, player dimensions, provider and video ID. It does not mean that every valid identifier produces every field, only that the tool asks endpoints intended to answer without a signed-in account.
Technical accessibility is neither permanence nor permission. An uploader can replace a thumbnail or title while its URL remains unchanged; YouTube or local policy can refuse a request; and rights can restrict reuse. A responsible record includes an access date and source, and describes an observation rather than an eternal property of the video.
What the tool shows — thumbnails in every size plus those public details, from two named hosts
ToolAcre probes eight JPEG names: five poster variants and three hq frame stills. It reads the body, decodes actual dimensions and treats a 120×90 response for a larger candidate as YouTube’s placeholder rather than proof that the requested artwork exists. The interface also provides five WebP poster URLs, but those remain links because their path does not grant the cross-origin access required for ToolAcre to read and save the bytes.
The metadata branch requests www.youtube.com/oembed with a canonical watch URL and format=json. ToolAcre exports selected normalized fields as JSON, Markdown, CSV or text, not arbitrary properties or oEmbed HTML. Its privacy-enhanced iframe is built separately from the validated ID rather than trusted from the endpoint.
What it will not do — download the video, log in, read private data or bypass restrictions
The viewer does not download video or audio, log in, scrape the watch page, resolve channels or playlists, or retrieve captions. It does not synthesize views, likes, descriptions, tags, duration, upload date, comments or account-only fields. Those omissions are part of the contract. If a citation needs duration or publication date, obtain it from another permitted source and label that source instead of filling the gap with an inference.
Private, deleted and age-restricted records do not expose the required signed-out material. An ID can pass the local eleven-character shape test while all later requests fail, because syntax identifies a possible reference rather than current availability. The tool performs no login or access bypass. A missing record should remain missing, with its failure category documented, rather than being reconstructed from a search result, cached page title or unrelated thumbnail.
Why the boundary matters — respecting the uploader, the platform's terms and the reader's own risk
A transparent boundary protects uploader and reader alike. It prevents a convenience tool from being represented as an access mechanism and lets a researcher state exactly which observations came from public endpoints. The decoded image proves what bytes arrived; oEmbed proves which normalized fields were returned; neither proves who owns the material, why it was published, or whether a proposed reuse is authorized.
Platform terms, creator rights, licences and project-specific permissions remain the user’s responsibility. The implementation can demonstrate request mechanics and output fields, but it cannot issue a legal conclusion. Keep permission evidence beside downloaded assets, avoid implying endorsement, and prefer an embed or a direct permission request when copying is unnecessary or the intended presentation exceeds the rights you can document.
Worked example: public evidence only, without predicting unlisted-link behavior
For a known public video, retain the input URL and access date, then compare the normalized title and channel with the visible source and inspect each decoded thumbnail row. A maxresdefault request may return genuine 1280×720 artwork, a smaller variant may be available, and another candidate may return a placeholder. Report those results independently rather than reducing the run to a single available-or-missing label.
For a private or deleted reference, absence is expected; signed-out age-restricted material likewise cannot be recovered. The implementation does not establish one universal rule for unlisted links, so do not predict their behavior from the ID format or from one test. Check only material you are permitted to examine and record the observed response. Evidence is strongest when input, date, browser context and individual outcomes travel together.
Takeaway: signed-out public scope with explicit private, deleted and age-restricted limits
Before Fetch, parsing is local and no existence check occurs. After the click, eight image GETs and one oEmbed GET go directly to Google with credentials omitted, no referrer, no-store and redirects followed. Google receives those requests and the browser Origin header; no ToolAcre proxy receives the ID or returned content. The operation is therefore disclosed and inspectable, but not local after Fetch.
Interpret every result within the signed-out boundary. Retry a transport interruption, but do not treat retries as a way to expand access; retain placeholders and HTTP refusals as distinct observations rather than converting them into guessed metadata. The viewer remains a current public-evidence tool, not a historical database, rights oracle or mechanism for recovering restricted records.