ColorKitFree OG image generator
OG image generator that shows you the crop
Free, no signup, no render server: give it a headline, choose a backdrop, and the card is composed at exactly 1200 × 630 in your browser and saved as a PNG or a JPEG. The preview shades what each network throws away — 15 pixels off the top and bottom when X crops to its 2:1 card, 40 pixels off each side in a 16:9 embed — so you find out before you publish rather than after. Alongside the file it writes the whole meta block: og:image with an absolute URL, og:image:width, og:image:height, og:image:type, twitter:card, and the og:image:alt nearly every other generator omits.
- 100% free
- No signup
- 1200 × 630
- Alt tag included
- PNG or JPEG
Card text
Press Ctrl+V anywhere on the page to drop in a headline — or an https:// URL, which lands in the image-URL field instead — no need to click the field first.
Background
Drop a screenshot or photo, up to 5.00 MB.
Type and layout
- Canvas
- 1200×630 · 1.91:1
- Title set at
- 78px over 0 lines
- Title contrast
- 11.52:1 AAA for large text
- Subtitle contrast
- 6.82:1 clears 3:1
- Encoded
- encoding…
The tags that point at it
<meta property="og:title" content="Why our build got 40% faster after we deleted the cache"> <meta property="og:description" content="Three weeks of profiling, and the fix was one line in the wrong place."> <meta property="og:image" content="https://example.com/og/why-our-build-got-40-faster-after-we-del-0000000.png"> <meta property="og:image:type" content="image/png"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="630"> <meta property="og:image:alt" content="Engineering — Why our build got 40% faster after we deleted the cache — Three weeks of profiling, and the fix was one line in the wrong place. — yoursite.com"> <meta name="twitter:card" content="summary_large_image"> <meta name="twitter:image" content="https://example.com/og/why-our-build-got-40-faster-after-we-del-0000000.png"> <meta name="twitter:image:alt" content="Engineering — Why our build got 40% faster after we deleted the cache — Three weeks of profiling, and the fix was one line in the wrong place. — yoursite.com">
The 0000000 in the filename is a hash of the encoded bytes. Change the card and it changes with it, which is what forces Facebook, LinkedIn and Slack to fetch again instead of serving the copy they cached.
How to make an OG image
Three steps: set the words, check the crop, take the file and the tags.
Write the headline the way it will be read
Type the eyebrow, title, subtitle and footer line. The title is measured with the canvas text metrics and stepped down from 78 px to 38 px in 2 px increments until it fits three lines at 1.16 leading; a word longer than the 1,056 px content box — a URL, a package name — is broken by code point rather than allowed to run off the edge. Keep the title under about 70 characters if you want it at full size: past that the auto-fit has already dropped two steps, and a feed renders the card at roughly half its pixel size.
Choose a backdrop and look at what gets cropped
Pick a flat color, a two-stop gradient at any angle, or drop a photo up to 5 MB that is cover-fitted into the frame with a black overlay from 0 to 90 percent. Turn on the crop shading: the dark strips are the pixels that disappear when X crops 1200 × 630 to its 2:1 card, when a 16:9 embed takes the sides, and when a messaging app reduces the card to a square. The contrast readout scores the title and the subtitle against the flattened backdrop, sampling a photo's average color from a 1 × 1 downscale so the number still means something over an image.
Take the file and the tags together
Download writes a PNG, or a JPEG at quality 0.90 when a photographic background pushes the PNG past the 5 MB X accepts. The filename ends in a seven-character hash of the encoded bytes, which is what makes a changed card a changed URL. Paste the folder your images are served from into the URL field, copy the meta block, and drop it in the document head — it carries og:image with an absolute URL, og:image:width 1200, og:image:height 630, og:image:type, og:image:alt and twitter:card set to summary_large_image.
Technical specifications
| Canvas | 1200 × 630 exactly, 1.91:1, drawn at 1:1 with no upscaling — the size Facebook and LinkedIn document for a large card |
|---|---|
| Crop budget shown | 15 px off the top and bottom for X's 2:1 summary_large_image, 40 px off each side for a 16:9 embed, 285 px off each side for a square thumbnail |
| Headline fitting | 78 px down to 38 px in 2 px steps, up to 3 lines at 1.16 leading; a word wider than the 1,056 px default content box is broken by code point, and an over-long title is ellipsized rather than overset |
| Subtitle | 30 px, up to 2 lines at 1.38 leading, drawn at 26 percent toward the backdrop in Lab so it reads as secondary without dropping below 3:1 |
| Type families | 5 device-resident stacks — no webfont is loadable under this site's default-src 'self' policy — with a width probe that reports which ones this machine is missing instead of letting the canvas substitute in silence |
| Output | Opaque PNG, or JPEG at quality 0.90, with the byte count checked against the 5 MB X accepts and the 8 MB Facebook accepts |
| Cache-busting filename | A 7-character base-36 FNV-1a hash of the encoded file, so the URL in the meta block changes exactly when the pixels do |
| Background photo | Up to 5 MB, cover-fitted and dimmed 0-90 percent; read with a blob URL inside this tab and never sent anywhere, with its average color sampled from a 1 × 1 downscale so the contrast figure still resolves |
Frequently asked questions
Why 1200 × 630 rather than 1200 × 600?
Because 1200 × 630 is the size Facebook's own sharing documentation asks for, and 1.91:1 is the ratio it lays a large card out at. X wants 2:1 instead, and gets there by center-cropping, which removes 15 pixels from the top and 15 from the bottom of a 630-tall card. Shipping 1200 × 600 to satisfy X would leave Facebook 30 pixels short of its recommendation and risks the small-thumbnail layout on a bad day. Keep the canvas at 630 and keep everything that matters inside the middle 600 — that is exactly what the crop shading in the preview is for.
I replaced the image but the old one still shows up. Why?
Every scraper caches the card against the page URL and the image URL, so new bytes at the same path are simply not fetched. Facebook holds a scrape for around 30 days, LinkedIn for 7, and Slack for hours. There are two fixes and you want the first: change the filename, which is why the download here ends in a hash of the file's own bytes and why that hash appears in the meta block. Failing that, force a re-scrape by hand in Facebook's Sharing Debugger or LinkedIn's Post Inspector — X has no manual invalidation at all and simply refetches when its cache expires.
Can og:image be a relative path like /og/card.png?
No — og:image must be an absolute URL with a scheme and a host, and a relative path fails silently with no error anywhere. The crawler is not a browser sitting on your page; it reads the markup and takes the content attribute as given, so /og/card.png resolves against nothing and the card renders with no image. This is the single most common reason a card that looks right in a local preview is blank when it is actually shared. If you build metadata in a framework, this is what a base-URL setting exists for: in Next.js, metadataBase is what turns a relative image path into an absolute one before the tag is written.
Do I need twitter:image as well as og:image?
No, X falls back to og:image when twitter:image is missing, so the only X-specific tag you genuinely need is twitter:card set to summary_large_image. Two details trip people up anyway. The Open Graph tags use property while the X tags use name — property="twitter:card" is tolerated in practice but is not what the card spec describes. And without twitter:card at all, X renders the link as a small square summary rather than the wide card, no matter how large the image is.
What does og:image:alt actually do, and how long can it be?
It is the text a screen reader announces where the card image sits, on Facebook, LinkedIn and X alike, and Facebook documents a 420-character ceiling for it. Almost every card generator skips it, which is why a shared link so often reads as nothing at all to someone using a screen reader. For a card that is type on a background, the honest alt text is the words on the card in reading order — that is what this page prefills. Rewrite it when the photograph behind the words carries meaning of its own, and note that it describes the image, not the page, so it should not duplicate og:description.
Why do the emoji in my card look wrong on someone else's machine?
They do not change — that is the problem. The glyphs are rasterized here, on your computer, using whatever emoji font your operating system ships, and then frozen into the PNG. A card composed on macOS carries Apple's emoji artwork to every Windows and Android viewer, which is usually fine but is not what those viewers see anywhere else on the page. The same freezing works in your favor for text: because the letters are pixels by the time anyone sees them, the font only has to exist on the machine that made the card, and this page tells you when a family such as Impact is missing rather than substituting one silently the way a canvas otherwise would.
My card reads fine here but is unreadable in the feed.
A timeline renders a 1200-pixel card at around 500 to 600 CSS pixels wide, so every size on the canvas is effectively halved. A 38-pixel headline — the smallest this page will auto-fit to — lands at about 19 pixels in a feed, which is body-copy size; anything smaller than that is why the auto-fit stops there and ellipsizes instead. The other half of the problem is contrast: cards are read outdoors on phones, and a title under 3:1 against its backdrop is the first thing to disappear. Both numbers are shown live above the download button.
About Open Graph images
The Open Graph protocol asks for four properties and og:image is one of them, but the tag itself is only a URL — everything useful about how the card is laid out comes from the ones next to it. Declaring og:image:width and og:image:height lets a scraper reserve the large-card layout on the first render instead of waiting for the fetch to tell it the shape, which is why a freshly shared link sometimes appears as a small thumbnail and then corrects itself the second time. Two rules about placement have no error message attached and cost people afternoons: the tags must be in the document <head> of the HTML the server sends, and og:image must be an absolute URL. No card scraper runs JavaScript, so a tag a client-side router injects after load does not exist as far as Facebook, LinkedIn, Slack or X are concerned.
The awkward part of the format is that there is no single card shape. 1200 × 630 is 1.91:1 because that is what Facebook documents; X lays out summary_large_image at 2:1 and center-crops to get there, taking 15 pixels off the top and bottom; a 16:9 embed keeps the height and shaves 40 pixels off each side; a square thumbnail in a messaging app keeps only the middle 630 columns and discards 285 on each side. Anything you place in a corner is therefore in the one region every crop agrees to attack, and the rounded corners X and LinkedIn paint over the card eat a few more pixels on top of that. Type has a second, quieter problem: a canvas that cannot find the family you asked for substitutes another without saying so, and under a default-src 'self' policy no webfont can be loaded at all. That matters less than it sounds, because the glyphs are pixels by the time anyone else sees them — the font only has to exist on the machine that composed the card.
Most of what goes wrong afterwards is caching. Scrapers key their cache on the URL and hold it for days, so replacing the bytes at /og/default.png leaves the old card circulating until the cache expires or you re-scrape by hand; the content hash in the filename here exists to make that a non-event. The rest is a checklist the hosted card services and the render-on-request approaches both tend to skip: an alt attribute, an opaque background — networks re-encode what you send and transparency is not guaranteed to survive — and a file small enough that the fetch does not time out. If your artwork starts as a vector, rasterize it to the exact frame with SVG to PNG and run the source through the SVG optimizer first, since a card background is one place stray editor metadata costs real bytes; a logo you only have as a bitmap scales properly once traced to paths. A launch usually needs the small square assets in the same pass — the favicon generator lays out the ladder of sizes, the ICO converter packs them into the one file Windows still reads, and the avatar generator covers the byline picture that sits next to the card in a feed.
Where the card is composed
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
A photo you drop in as a background gets a temporary address only this tab can resolve, goes straight into the canvas and is never uploaded — which also means the finished card is assembled on your machine rather than on a rendering server that would have to be told your headline before your post goes live.