---
title: "OG Images for Every Page"
description: "Give every page on your website an automatic, up-to-date social sharing image with one URL pattern."
published: "2026-08-23"
author: "Jeffrey Needles"
canonical: "https://htmlcsstoimage.com/blog/og-images-for-every-page"
---
When someone shares a link from your site, its Open Graph image becomes the large preview in Slack, LinkedIn, Facebook, Messages and other apps.
Most sites use one fallback image for every URL. Creating a specific image for each article, product or profile usually means adding image creation to the publishing process. Nowadays, the barrier has dropped with AI image generation, but those images are often impersonal, generic or don't provide real structured information for the link being shared. We talk about our own adventure in this arena in a [previous post](/blog/using-hcti-for-our-own-og-images).
We've historically offered a few different pathways for creating images - from simple POSTs to signed and secure HMAC URLs. While these work great for a more advanced user or developer, we wanted something **simpler**.
With **OG Image Configs** you set up your domain in your dashboard, and you can place a URL onto your page (no complicated code required). HCTI uses the path to find the source page and create its image when a crawler requests it.
You do not need to make an API request when the page is published, expose an API key or create a signed URL for every page.
## One Website, One Image URL Pattern
An OG Image Config connects an exact website origin, such as `https://example.com`, to a domain ID provided in your dashboard.
The path of each page is then added to the end of the image URL:
| Page | OG image |
|:-----|:---------|
| `https://example.com/` | `https://hcti.io/v1/og/DOMAIN_ID/` |
| `https://example.com/blog/hello` | `https://hcti.io/v1/og/DOMAIN_ID/blog/hello` |
| `https://example.com/products/red-shirt` | `https://hcti.io/v1/og/DOMAIN_ID/products/red-shirt` |
The image path matches the page path. `/blog/hello` gets its content from `/blog/hello`, and `/products/red-shirt` gets its content from `/products/red-shirt`.
Add that matching URL to the page's metadata:
```html
```
When a social crawler asks for the image, HCTI visits the corresponding page, reads its metadata and renders the image. We cache the result instead of rendering it again for every share.
## Screenshot the Page or Use a Template
Each config has two rendering modes.
### Page Screenshot
Page Screenshot mode captures the page itself. It can use the full viewport or capture one element with a CSS selector. A store might capture its product hero, while a portfolio could capture the featured project section.
You can also include a purpose-built social card directly in the page and keep it hidden from normal visitors:
```html
Example Blog
Each Page Gets Its Own Social Card
```
The element remains `display: none` in the normal page. Before HCTI takes the screenshot, the `hcti:css` value reveals it, and `hcti:selector` limits the capture to that element. The card can use the page's existing title, product data, template variables, fonts and CSS instead of maintaining the same content in a separate image system.
The config holds the defaults for the site. An individual page can override details such as its selector, viewport or render delay in its metadata.
### Template Values
Template Values mode renders the same HCTI template for every page, populated with data from that page. A blog can insert the article title and author. A store can insert the product name, image and price. A directory can reuse one layout for every profile.
HCTI can map the page title, description, Open Graph tags or custom metadata to template variables. If the information already exists in the page, you do not need to maintain another copy for the image.
## Platform-Specific Image Sizes
Social platforms do not all display link previews at the same dimensions. A wide image that fits Slack or Facebook is not the shape Pinterest or Instagram prefers.
A config can return one image everywhere, fit one render into each platform's dimensions or render each size separately. Separate renders let a responsive page or template rearrange itself for square, portrait and landscape previews. The URL in your page stays the same.
## Built for Existing Websites
OG Image Configs are for public sites where each URL should have its own social image, without a separate image-generation backend. That includes:
- Blogs and documentation sites with a page for every article
- Ecommerce stores with many product and collection pages
- CMS-driven marketing sites
- Directories, portfolios and public profiles
- Static sites without a server-side API call
We have setup guides for [Shopify, Squarespace, Webflow, Wix, WordPress, Jekyll, Astro and Sitepress](https://docs.htmlcsstoimage.com/guides/og-images/). Each platform puts the image metadata in a different place, but they all use the same path-based URL.
## Keeping Images Current
Each config has a refresh interval that controls how often HCTI checks a page for new metadata. A changed title, description or template value can produce a new image without changing the public URL.
If your publishing system has an update number or timestamp, you can expose it as `hcti:content_version`. HCTI then treats that edit as a new version of the image while its URL remains stable.
## How It Works
The URL in `og:image` is not the URL of one permanently saved image. It is a stable route that tells HCTI which config and source page to use.
Take this image URL:
```text
https://hcti.io/v1/og/DOMAIN_ID/products/red-shirt
```
`DOMAIN_ID` selects the OG Image Config. Everything after it becomes the path on the website origin connected to that config. If the origin is `https://example.com`, HCTI reads `https://example.com/products/red-shirt`.
From there, a request moves through a few steps:
1. **Find the config.** HCTI loads the domain, rendering mode, refresh interval and image-size settings associated with the domain ID.
2. **Check the stored metadata.** On the first request for a path, there is nothing to reuse, so HCTI needs to visit the source page. On later requests, HCTI first checks when the metadata was last read, the config's refresh interval and any usable cache headers returned by the site. If the metadata is still fresh, the request continues with the stored copy and never touches the source website.
3. **Refresh the page when needed.** When the metadata is missing or stale, HCTI fetches the matching source URL and reads its title, description, Open Graph tags and any `hcti:` or `html:tv:` metadata. If an existing image is available, HCTI can return it immediately and refresh the metadata in the background. An `ETag` also lets HCTI make a conditional request, so a `304 Not Modified` response can update the check time without downloading the page again. To prevent abuse, query strings are ignored when choosing the source page.
4. **Build the render inputs.** Page Screenshot mode combines the source URL with its configured viewport, selector and page-level overrides. Template Values mode maps the stored page metadata into the selected template.
5. **Choose the dimensions.** The config either uses one image everywhere, adapts a shared render or selects a platform-specific render size based on the crawler requesting the image.
6. **Return a cached image or render a new one.** HCTI uses those effective inputs to look for an existing image. If they have not changed, it returns that result. Otherwise, Page Screenshot mode opens the source page in Chromium, while Template Values mode renders the populated template. The new result is stored behind the same public URL.
We intentionally do not fetch the source page for every image request. Social crawlers retry requests, and several platforms may ask for the same card. Turning each request into a visit to the source website would add unnecessary traffic and make the image depend on that site responding quickly every time. The metadata cache and background refresh limit how often we contact the origin while letting crawlers receive an image immediately.
There are three caches involved: HCTI's page-metadata cache, HCTI's rendered-image cache and the social platform's own link-preview cache. Refreshing either HCTI cache does not force every platform to discard its copy; that cache still has to expire or be refreshed through the platform's tools.
This separation is what keeps the URL stable. Your site only needs to describe which page the image belongs to. The config owns how that page becomes an image, and HCTI handles the fetch, render and reuse work when the image is requested.
## Get Started
Create an [OG Image Config in the dashboard](https://htmlcsstoimage.com/dashboard/og-configs/new), enter your website origin and choose Page Screenshot or Template Values.
The complete [Open Graph image guide](https://docs.htmlcsstoimage.com/getting-started/og-images/) covers configuration, image sizes, refresh behavior and page-level options. You can also use the [Social Card Previewer](https://htmlcsstoimage.com/tools/social-card-previewer) to check how a published page will look when it is shared.
Example Blog
Each Page Gets Its Own Social Card