Generate OG images from a URL, no design tool needed

Making a share image by hand is the slow path. You open a design tool, set a canvas to 1200 by 630, retype the page title, eyedrop your brand colour, place the logo, export, and upload. Then the title changes and you do it again. None of that work is design. It is data entry, and a machine can read the data off the page you already published.

This is what generating an image from a URL means: you paste the address of a page, and the picture is built from what that page already declares about itself. No canvas, no fonts to pick, no logo to drag into place. This post covers what actually gets read off a page, what happens when a page says nothing, and how to go from one card to a card for every URL you own.

What a page already tells you

Every published page carries metadata that browsers and crawlers read but people never see. A share-image generator reads the same tags. The useful ones are few.

• og:title and <title>. The headline. The first is what platforms already show in a link preview, so it is the truest source for what the card should say.
• og:description and <meta name="description">. A subhead, when the layout has room for one.
• The favicon. Your mark, at the address every site keeps it. It becomes the logo on the card with nothing to upload.
• theme-color. A single declared brand colour, when the site sets one.
• An existing og:image. Not to copy, but to sample. The dominant colours in your current preview are your palette, and reading them back keeps a new card in family with the old one.

The three steps

1. Paste the URL. Any public page. Its own address, a blog post, a product page, a docs section.
2. Let it read. The page is fetched once, its head parsed, the favicon and any existing image pulled in and colours sampled. This takes a second or two, most of it network.
3. Adjust and export. The title, brand colour and logo arrive already filled. You change the layout or the wording if you want to, and download at 1200 by 630.

The point of the import is not that it is unchangeable. It is that step three starts from something correct instead of from an empty canvas.

When the page says nothing

Plenty of pages carry no Open Graph tags at all. That is the entire reason Open Graph meta tags are worth adding in the first place. A generator cannot invent a headline that was never written, so it falls back in order:

• No og:title, use the <title>.
• No description, leave the subhead empty rather than pad it.
• No favicon, fall back to the site name set as text.
• No declared colour, derive one from the image or use a neutral default.

A page with nothing readable still gives you a domain and a title, which is enough for a plain, correct card. The thinner the page's metadata, the more you finish by hand, and the better argument that is for fixing the page's tags so the next tool that reads them, a real crawler, has something to show.

The part people get wrong

Importing gives you a starting point, not a finished card, and two things still need a human eye.

The headline length. A page title written for a browser tab is often too long for a card read at thumbnail size. Cut it to the few words that carry the meaning. A share image is glanced at in a moving feed, not read.

The crop. Whatever image gets sampled, the card renders at 1200 by 630, and that ratio crops differently on every platform. Keep the headline clear of the edges. The full set of dimensions and safe zones is in the OG image size guide.

From one URL to every URL

Doing this once by hand is fine for a landing page. A site with a hundred posts needs the card to follow the content without anyone opening a tool each time. There are two honest ways to get there.

Build time. Render a card per page when the site builds, keyed on the same title the page reads from. The cards are static files, cached like any asset, and only rebuild when the content does. This is the right answer for a blog or a docs site where the pages are known ahead of time.

Request time. A single endpoint that takes the page's title and brand as parameters and returns a freshly drawn image, cached by those parameters so identical requests never render twice. This suits a site whose pages are not all known in advance, a user profile or a generated report, where a card has to exist for a URL nobody listed at build.

Both replace the design tool with the page's own data, which is the same move the paste-a-URL import makes, run automatically instead of once.

Checking the result

Whatever made the image, the test is the same, because a crawler only sees the HTML your server sent. View the source of the deployed page and confirm the image tag is there and absolute:

curl -s https://example.com/my-post | grep -i 'og:image'

If that prints a full https:// URL, the picture is wired in. Then run the page through the Facebook Sharing Debugger and the LinkedIn Post Inspector, which both re-crawl on submit and show you exactly the card a platform will build. If the tags are right but the old picture still shows, that is a caching problem rather than a markup one, and it has its own fix.

The short version

A share image is a picture of data your page already holds. The title is written, the colour is declared, the mark is at its usual address. Generating from a URL is just reading those back and drawing them at the right size, so the work that is left is the small human part: cutting the headline, checking the crop, and adding the one tag that points the world at the result.