ScreenshotNeo

BlogHow-to

How to Generate Social Preview Images from Webpages Using Cloudinary

Build social preview images with Cloudinary transformations, then add the generated URL to your page’s Open Graph metadata.

By the ScreenshotNeo team4 October 20268 min read

To generate a social preview image with Cloudinary, create or choose a source image, build a Cloudinary delivery URL with the crop, resize, and overlay transformations you need, then put that URL in your webpage’s Open Graph image metadata. For Next.js, Cloudinary documents the CldOgImage component and getCldOgImageUrl helper. Cloudinary transforms images; the documentation reviewed here does not establish that it renders an arbitrary webpage into a screenshot or automatically extracts that page’s content.

The basic flow is:

  1. Prepare a base image in Cloudinary, or configure remote image fetching.
  2. Compose a social-card image URL with transformations and optional text or image overlays.
  3. Expose that URL as the page’s Open Graph image metadata.
  4. Check the rendered page metadata and ensure the image URL can be fetched by the services that need it.

1. Decide what the image should contain

A social card can use a reusable background image with a title and brand mark, or a page-specific image selected by your application. Your code supplies the page title, image, and any other content to the card-generation logic. A Cloudinary delivery URL transforms an image asset; it does not by itself read a webpage and turn its contents into artwork.

Choose an uploaded Cloudinary asset when you want direct control over the source and its lifecycle. Choose remote fetch when the source is already hosted elsewhere and your Cloudinary environment permits fetching it. Remote fetch depends on the source being a supported media file, fetch security settings, and any allowed-domain restrictions.

2. Generate an image URL with Cloudinary

A Cloudinary delivery URL is built from the cloud name, asset type, delivery type, optional transformations, version, public ID, and file extension. In a typical workflow, the application constructs a URL from a known asset and applies transformations for the desired composition. Cloudinary supports dynamic transformations such as resizing, cropping, and overlays; SDK helpers can construct delivery URLs and image tags. See Cloudinary’s Image Transformations documentation.

For page-specific cards, pass the title and selected artwork from your application into the generation logic. You can use a base image, add a text layer with a specified font and size, style and position it, or place an image overlay such as a logo. Cloudinary documents overlay and underlay transformations, including layer placement and transformation.

The exact transformation string depends on your asset IDs, cloud name, design, and SDK version. A URL helper is usually easier to maintain than hand-concatenating a long transformation URL. For example, with the Cloudinary JavaScript SDK, the general shape is:

import { v2 as cloudinary } from 'cloudinary';

cloudinary.config({
  cloud_name: process.env.CLOUDINARY_CLOUD_NAME,
  api_key: process.env.CLOUDINARY_API_KEY,
  api_secret: process.env.CLOUDINARY_API_SECRET,
});

const cardUrl = cloudinary.url('social-cards/base', {
  secure: true,
  transformation: [
    { width: 1200, height: 630, crop: 'fill' },
  ],
});

console.log(cardUrl);

This example constructs a transformed delivery URL for an asset named social-cards/base. The dimensions and crop are illustrative implementation choices, not universal platform requirements. Confirm the current requirements for the networks and preview surfaces you target before choosing dimensions or formats. Keep API secrets on the server; a delivery URL intended for page metadata should not expose credentials.

3. Add the URL to Next.js Open Graph metadata

Cloudinary’s Next.js SDK documents CldOgImage for generating Open Graph/social card images and getCldOgImageUrl for creating a social-card image URL for App Router metadata. Follow the current SDK documentation for installation, version-specific props, and metadata integration: Cloudinary Next.js integration.

For App Router pages, the metadata must include the generated URL in openGraph.images. The helper/component configuration can vary by SDK version, so use the documented API for the version installed in your project. The integration pattern is:

import { getCldOgImageUrl } from 'next-cloudinary';

const ogImageUrl = getCldOgImageUrl({
  // Add the asset and transformation options documented for your SDK version.
});

export const metadata = {
  openGraph: {
    images: [{ url: ogImageUrl }],
  },
};

For a page that computes metadata from route data, export an async generateMetadata function and return the page-specific Open Graph image URL there. Keep the title or other per-page values in your application data, and pass them into the image-generation helper according to its documented options. The CldOgImage component is another documented option when generating the social card from a Next.js page.

4. Use the generated URL in other frameworks

In another framework, generate a Cloudinary delivery URL using the SDK or URL structure, then add it to the HTML head as Open Graph metadata. The metadata URL should be absolute and publicly fetchable by preview crawlers.

<meta property="og:title" content="Page title">
<meta property="og:description" content="Page description">
<meta property="og:image" content="https://res.cloudinary.com/YOUR_CLOUD/image/upload/w_1200,h_630,c_fill/v1234567890/social-cards/base.jpg">

Replace the example cloud name, version, asset ID, and transformations with values for your project. Ensure the server renders these tags in the HTML response where crawlers can find them; client-only metadata updates may not be visible to every crawler.

5. Fetch a remote source image when needed

Cloudinary’s fetch delivery type can retrieve a remote image and deliver it through a Cloudinary URL with transformations. The source must resolve as supported media, and the environment’s fetch settings determine whether unrestricted fetching, signed URLs, or an allowed-fetch-domain list applies. See Cloudinary’s remote media fetch documentation.

Remote fetch is useful when an application already publishes page-specific source images elsewhere. It does not remove the need for your application to decide which image and title belong on the card. Also account for caching: fetched assets are cached, and changing the remote source does not necessarily refresh the fetched asset and its transformed versions automatically. If sources change, plan a refresh strategy, such as using a new source URL or a documented invalidation approach for your setup.

6. Verify the metadata and image

  1. Open the page’s server-rendered HTML and confirm the og:image value is the URL you generated.
  2. Open that image URL directly and confirm it returns the expected image rather than an error or access challenge.
  3. Check that the composition remains readable at the size and crop used by your target preview surfaces.
  4. When a source image or transformation changes, account for Cloudinary’s cached fetched or derived asset behavior.

Image URL generation and page metadata are separate steps. A valid transformed image URL does not guarantee the webpage is publishing it in the right metadata field.

7. Performance, reliability, and cost

Cloudinary generates dynamic transformations on request and caches derived assets for later requests. Reusing stable URLs can therefore reuse the derived asset, while frequently changing transformation inputs or source URLs can create additional variants to manage. There is no single performance or cost result that applies to every account and workload.

Transformation operations may count toward account usage. Check your Cloudinary plan and usage dashboard for the applicable limits and charges instead of assuming transformations are free. Remote fetch adds dependencies on source availability, allowed-domain settings, fetch security, and cache refresh behavior. For reliable page metadata, generate the URL from known inputs and confirm that the resulting image can be publicly retrieved.

8. Troubleshooting

Symptom Likely cause What to check or change
The page preview has no image The page does not emit an og:image tag, or metadata is only set client-side. Inspect the server-rendered HTML and wire the generated URL into the framework’s metadata mechanism.
The image URL returns an error The cloud name, public ID, version, delivery type, or transformation is wrong, or the source asset is unavailable. Open the URL directly and compare each URL segment with the asset and transformation configuration.
A remote image cannot be fetched Fetch is disabled, the remote host is not allowed, a required signature is missing, or the source is not a supported image. Review fetch security settings and allowed domains, use the required signing method, and confirm the remote source resolves to an image.
The remote source changed but the delivered image did not The fetched asset or transformed result is cached. Use an explicit refresh strategy supported by your Cloudinary setup; changing the origin file alone may not refresh the cached result.
The card shows an old title or artwork The application is reusing a cached asset URL or is not passing current page data into card generation. Check the inputs used for the page’s image URL and use a versioned or otherwise refreshed asset strategy.
The crop cuts off important content The selected crop mode or focal point does not suit the source image. Adjust crop and positioning transformations, or prepare a source image composed for the card layout.
Usage is higher than expected New transformation variants or fetched assets may affect account usage. Review Cloudinary usage and plan details; reuse stable transformations where practical and avoid generating unnecessary variants.

9. Or skip the browser setup

If your goal is to capture an actual webpage as an image, ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. Cloudinary’s reviewed documentation covers image transformations and social-card helpers; it does not establish arbitrary webpage screenshot rendering. ScreenshotNeo takes a webpage URL in one request and returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before the shot; those steps can be turned off. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. You can use a capture as an image source in a separate card-design workflow, then publish the resulting URL as page metadata.

Sign up for 1,000 free screenshots a month with no card.

FAQ

Does Cloudinary automatically read my webpage title and make a card?

The reviewed documentation does not establish automatic webpage reading or arbitrary page rendering. Your application supplies the content and image-generation inputs.

Can I use one social-card image for many pages?

Yes. Use a shared image URL when a common card is suitable, or generate page-specific URLs from each page’s data when the title or artwork should differ.

Do I need the Next.js SDK?

No. The SDK provides documented Next.js helpers. In other stacks, construct a Cloudinary delivery URL and place it in the page’s Open Graph metadata.

Will changing a fetched remote image immediately change every card?

Not necessarily. Fetched and transformed assets are cached, so define how your application will refresh or replace assets when their source changes.