When you share a link on social media, the preview image that appears is called the Open Graph (OG) image. It's essentially free advertising, a chance to catch someone's eye before they even click through. Most sites either use a generic logo or rely on a paid service to generate these dynamically. I do neither. I take a screenshot of every page on my website and use that as the OG image, for free.

Here's how it works and why I think it's a great approach for personal sites.

What are OG images and why they matter

Open Graph images are the visual previews that show up when a URL is shared on platforms like X, Facebook, LinkedIn, or messaging apps like WhatsApp and iMessage. They're defined by a <meta> tag in the page's HTML:

A good OG image makes the difference between someone scrolling past your link and actually clicking on it. It takes less than two seconds for someone to decide whether a social media post is worth their attention, so the preview image matters more than you might think.

The typical approaches (and what they cost)

There are a handful of common ways to handle OG images:

Static, one-size-fits-all image. Many sites just slap their logo on a solid background and call it a day. It works, but every page looks the same when shared. Not exactly compelling.

Dynamic generation with a framework. Tools like Vercel's @vercel/og library let you generate images on the fly using JSX-like templates. This is powerful but requires setting up API routes and designing templates in code. If you're using a static export (output: 'export' in Next.js), you can't use API routes at all.

Third-party OG image services. There's a growing market of SaaS tools that handle OG image generation for you:

These services work well, but they cost money, and for a personal site they're hard to justify.

My approach: screenshot everything at build time

My solution is simple. I have a build script that uses a headless browser to visit every page on my site, take a screenshot, and save it to a folder. Then each page references its own screenshot as the OG image.

The command is just:

That's it. The script spins up a headless browser (think Puppeteer or Playwright), navigates to each page including dynamic ones like individual blog posts, captures a screenshot at the right dimensions (typically 1200x630px, the recommended OG image size), and saves it.

You can see how this is wired up in the source code for my portfolio site.

Why screenshots work so well

The OG image ends up being a live preview of what the page actually looks like. When someone sees the link shared on social media, they get a real glimpse of the content and design rather than a generic template. It's like a thumbnail that says "here's what you'll get if you click."

If your site has a clean design, the screenshots are genuinely enticing. Even if the design isn't award-winning, it still gives people a concrete sense of what they're clicking into, which beats a plain logo every time.

The technical flow

Here's a simplified breakdown of what happens under the hood:

The whole process runs as part of the build pipeline, so the images are always up to date with whatever the site looks like at deploy time.

Tools that make this possible

The headless browser ecosystem has matured a lot. Two libraries dominate:

Both support setting custom viewport sizes, waiting for elements to load, and saving screenshots in various formats. A basic Playwright screenshot looks like this:

Since the script runs with Bun, the execution is fast and integrates neatly into the existing build toolchain.

The trade-off: dynamic pages need advance builds

There's one caveat with this approach. Because the screenshots are generated at build time, any new content that hasn't been built yet won't have an OG image.

For a blog, this means if you publish a new post but don't rebuild and redeploy, that post will be missing its OG image until the next build. Dynamic pages that are created after the last build, like a brand new blog entry, simply won't have a screenshot yet.

You have a few options to handle this:

If rebuilding every time feels like too much friction, that's where the paid services come in handy. Services like og:screen generate screenshots on demand when a social bot requests the image, so there's no build step needed. But again, that comes at a cost.

When this approach makes sense

This screenshot-based method is ideal for:

It's less ideal for large-scale sites with thousands of pages (build times add up), sites with frequently changing content that can't always be rebuilt, or teams where the build process is complex and adding a headless browser step isn't practical.

Wrapping up

OG images don't have to be complicated or expensive. If you have a personal site with a decent design, taking screenshots of your own pages is a free, effective, and surprisingly elegant solution. You get real page previews as your social share images, no third-party dependency, and full control over the process.

The only cost is a few extra seconds in your build step. That's a trade-off I'm happy to make.

References