Search DevTools

Jump to any tool or page

Open Graph Image Generator

Design a 1200×630 Open Graph image, see it unfurl on WhatsApp, Telegram, X, Slack and more, then download it or host it behind a URL you can drop straight into og:image.

Design

Unsaved

Preview

1200 × 630
devtools
$
Open Graph images that never look like an afterthought
Design once, host the URL, and every link you ship unfurls the way you meant it to.
devtools.dev

Where it unfurls

Real rendered file, not a browser approximation
title cuts at 65 · description at 120
No image set

Open Graph images that never look like an afterthought

Design once, host the URL, and every link you ship unfurls the way you meant it to.

devtools.dev

https://devtools.dev

11:42
Visual Creation

About Open Graph Image Generator

Compose an Open Graph preview image at 1200x630 and export it as PNG for use in og:image tags. The subtlety most people miss is that scrapers are not browsers: they fetch the raw HTML, never execute JavaScript, and resolve nothing relative — so an og:image written as /og.png is simply dropped by Facebook and Slack rather than being resolved against the page URL.

Related Visual Creation tools

Resume BuilderChart GeneratorSVG AnimatorIndian MapColor Palette

Frequently asked questions

Why is 1200x630 the standard, and what happens at other sizes?
1200x630 is a 1.91:1 ratio, which matches the large-card slot Facebook, LinkedIn and Slack render. Facebook requires at least 200x200 and recommends 1200x630 so the image survives retina downscaling; below roughly 600x315 it falls back to a small square thumbnail beside the text. Non-1.91:1 images are centre-cropped, so text near the top or bottom edge disappears. Keep the important content inside a safe area of about 1000x500 centred in the frame.
My og:image is correct in the HTML but the old one still shows. Why?
Every platform caches scrape results aggressively — Facebook holds them for around 30 days, LinkedIn for roughly a week, and Slack keeps an unfurl cache per workspace. Editing the tag does not invalidate that cache. Force a re-scrape through Facebook's Sharing Debugger, LinkedIn's Post Inspector, or by appending a cache-busting query string to the image URL itself. Twitter's Card Validator no longer purges, so a new image filename is the reliable route there.
Should og:image point to a static file or a dynamically rendered endpoint?
Both work, but a dynamic endpoint must respond fast and unauthenticated. Scrapers typically abort after five to ten seconds and never send cookies, so a route behind auth, behind a Vercel deployment protection wall, or doing a cold serverless start with font fetching will time out and yield no card. If you render on the fly, cache the response with a long Cache-Control max-age and immutable, and key the URL on content so cache busting is automatic.
Do I need og:image:width, og:image:height and og:image:alt?
Declaring width and height lets the scraper reserve the large-card layout before it has downloaded the file, which prevents the first share from rendering as a small thumbnail while the fetch is still in flight. They must match the actual pixels or the crop goes wrong. og:image:alt supplies alternative text for screen readers on Facebook and LinkedIn and is capped at around 420 characters. og:image:secure_url is legacy; serving the image over HTTPS in og:image is sufficient today.
Which image formats are safe for social cards?
PNG and JPEG are universally supported. WebP is decoded by Facebook and Slack but has historically failed on some LinkedIn and iMessage paths, and animated GIF is flattened to its first frame everywhere. SVG is rejected outright by every major scraper for security reasons. Keep the file under about 5 MB — Facebook's hard ceiling — and ideally under 300 KB, since some crawlers cut the download short and treat a truncated file as invalid.