Read Open Graph, Twitter card and JSON-LD metadata from any URL with one request
/v1/metadata returns title, description, canonical, favicon, language, Open Graph and Twitter tags and every JSON-LD block from the head alone. One credit.
In short
- GET /v1/metadata?url=… reads the first 512 KB of the page and returns title, description, canonical, favicon, lang, og, twitter and jsonLd.
- It is the endpoint for link previews, bookmarks, feed enrichment and 'what is this URL' checks in an agent. It never renders JavaScript.
- jsonLd is the raw array of every application/ld+json block, parsed, so products, articles, events and organisations come through with their schema.org fields.
Every link preview, every bookmark manager and every “summarise this URL” agent starts the same way: fetch the page and pull the tags out of the head. /v1/metadata does that step and stops there, so it is fast and costs one credit.
The request
curl "https://api.webscrapingapi.dev/v1/metadata?url=https://example.com" \
-H "X-API-Key: wsa_your_key"The response
{
"url": "https://example.com",
"finalUrl": "https://example.com/",
"title": "Example Domain",
"description": null,
"canonical": null,
"favicon": "https://example.com/favicon.ico",
"lang": null,
"og": {},
"twitter": {},
"jsonLd": [],
"elapsedMs": 380,
"credits": 1
}example.com is deliberately bare; a typical article page fills every field.
| Field | Where it comes from |
|---|---|
title | the <title> element, else og:title |
description | <meta name="description">, else og:description |
canonical | <link rel="canonical">, resolved to an absolute URL |
favicon | <link rel="icon">, the shortcut icon or the apple touch icon, resolved to an absolute URL; /favicon.ico when none is declared |
lang | the lang attribute on <html> |
og | every og:* property with the prefix removed: { "image": "…", "type": "…", "site_name": "…" } |
twitter | every twitter:* name the same way: { "card": "summary_large_image", … } |
jsonLd | each <script type="application/ld+json"> parsed; invalid blocks are skipped |
JSON-LD is the underrated part
Sites put their structured data in JSON-LD because search engines read it, and that makes it the most reliable machine-readable description of a page. A product page yields Product with offers.price; an article yields Article with datePublished and author; an event yields the dates and the venue. jsonLd hands you those objects parsed, in the order they appear, and you pick the @type you care about. For a general “tell me about this URL” tool, checking jsonLd before falling back to scraping the body saves a lot of selectors.
What it is not for
The endpoint never runs JavaScript and never reads past the first 512 KB, so it is not a way to get a page’s content. For the body use /v1/scrape with format=markdown or text. If a site injects its Open Graph tags with client-side code, which is rare but happens on some single-page apps, you will see the HTML fallbacks instead; that is a property of the site, and a scrape with render=true is the workaround.
Typical uses
Link previews in a chat or a CMS, enriching an RSS feed with images and descriptions, deduplicating bookmarks by canonical, and giving an agent a cheap first look at a URL before it decides whether to read the whole page. The metadata reference has the full field list.
Questions people ask
- Why only 512 KB?
- Metadata lives in the head, which is always at the top. Stopping early keeps the request fast and cheap; large pages still yield their tags.
- What if a page has no Open Graph tags?
- og is an empty object; title and description come from the HTML title and meta description. canonical is null when absent; favicon falls back to /favicon.ico on the final host.
- Is the favicon URL absolute?
- Yes. Relative icon links are resolved against the final URL after redirects.
- Does it follow redirects?
- Yes. finalUrl is where the page actually lived; url is what you asked for.