How to Create Open Graph Preview Images from URLs with Make
Use Make to retrieve a URL’s Open Graph metadata, reuse its existing image, or render a custom preview card. Follow the workflow, handle missing data, and choose the right image output.
To create Open Graph preview images from URLs with Make, first decide whether you need the page’s existing Open Graph image or a new, custom-designed card. Use Make’s OpenGraph.io Site Lookup action to retrieve Open Graph information. Download the returned image if you want to reuse it. To create a designed card from the page’s metadata, map the data into Make’s HTML/CSS to Image action. If you want an image of the live webpage itself, use Make’s separate screenshot-of-a-URL action.
These outputs are different: metadata lookup retrieves information that a page exposes; HTML/CSS rendering creates an image from a design you supply; a URL screenshot captures the page as a webpage. The right choice depends on what the destination should display.
1. Choose the output you need
| Goal | Make approach | What you get |
|---|---|---|
| Reuse the image already associated with a page | OpenGraph.io Site Lookup, then download the returned image URL | An existing image file, if the lookup returns an image and Make can access it |
| Create a consistent branded card from URL metadata | Site Lookup, map fields into an HTML/CSS template, then HTML/CSS to Image | A newly rendered PNG, JPG, or WebP card |
| Show the page as it appears in a browser | Make’s screenshot-of-a-URL action | A webpage screenshot, rather than a designed card |
Make lists Site Lookup as an action for getting Open Graph information from websites. Its HTML/CSS to Image integration converts supplied HTML/CSS into PNG, JPG, or WebP. Make lists URL screenshots separately, so don’t treat a screenshot as the same thing as a custom card.
2. Build the Make scenario
- Choose a URL source. Start with a trigger or module that provides the page URL, such as a URL submitted through a connected app. A Make scenario is a workflow made from modules, and module outputs can be mapped into later modules.
- Resolve short links when needed. If the input may be a short URL and a downstream step needs the final destination, use Make’s Resolve URL action. It follows redirects and returns the resolved URL. You can pass that result to the lookup or capture step.
- Look up the page. Add OpenGraph.io’s Site Lookup action and map the source URL into it. Run the scenario with a representative URL and inspect the actual output before mapping fields. The returned fields depend on the service and the target page, so do not assume every page supplies a title, description, or image.
- Branch on whether an image URL exists. If the lookup returns an image URL, download it with an HTTP download step when the next module requires an image file. If there is no usable image URL, choose a fallback: skip the image, create a card from the available metadata, or capture the page itself.
- Render a custom card if desired. Create a reusable HTML/CSS layout and map the available title, description, image URL, and other content into it. Send that HTML/CSS to Make’s HTML/CSS to Image action and choose PNG, JPG, or WebP according to the destination’s accepted input.
- Send the result to the destination. Map either the rendered/downloaded file or a public image URL into the destination app. Check what that app accepts. For example, Make lists Google Docs actions that insert an image using a URL or replace an existing image with a URL; other destinations may have different requirements.
- Add error handling and test representative URLs. Account for redirects, missing metadata, inaccessible images, request failures, and destination restrictions. Test pages that include metadata and pages that do not.
3. Map metadata into a designed card
A custom card is useful when you want the same layout for many URLs. Keep the template separate from the scenario’s data: the template defines the design, while mapped values provide the page-specific content. Before relying on a field, inspect a real Site Lookup run and confirm that it exists for the pages you expect to process.
- Design the card in HTML/CSS with space for optional fields.
- Map the returned title and description into the corresponding template values when present.
- Map an image URL only when the lookup returns one that can be fetched or rendered by the chosen action.
- Set the HTML/CSS to Image output format to PNG, JPG, or WebP based on the destination’s requirements.
- Map the generated image output into the next module and confirm that it receives a file or URL in the form it expects.
Make’s integration listing confirms the conversion formats, but the available fields and successful retrieval of a particular page’s metadata or image depend on the service response and target site. Verify those in the scenario’s actual run history.
4. Retrieve an existing Open Graph image
If your goal is to reuse the image associated with the page, don’t send the page URL directly to the HTML/CSS renderer and expect it to discover the metadata. First use Site Lookup, inspect the returned image URL, and then download that URL if the next step needs an image file. A metadata lookup does not itself mean that a custom image has been designed or that the returned image is already a downloadable file.
If the image URL is absent, private, expired, or otherwise inaccessible to the scenario, handle that as a missing-image case. You can continue with text-only metadata, render a card without the source image, or route the URL to a page screenshot step if a screenshot suits the use case.
5. Use Make’s HTTP app when a request is needed
Make’s HTTP app can make requests to URLs and parse responses into mappable data. Use it when your workflow needs a direct HTTP request or when an API/webpage response must be parsed. Make requires HTTPS and rejects unverified self-signed certificates. If the target requires authentication, configure the request for that service and account for its access controls.
For URL inputs that redirect, Make’s Resolve URL action can return the final URL. Whether a target page permits access, exposes metadata, or serves an image to the workflow depends on that target; test the URLs you intend to process.
6. Select screenshot or card rendering
| Question | Use a URL screenshot when… | Use HTML/CSS to Image when… |
|---|---|---|
| What should the image show? | The webpage itself | A designed card populated with mapped content |
| How much layout control do you need? | You want the page as captured by the screenshot action | You want to define a reusable layout in HTML/CSS |
| What must be accessible? | The screenshot action must be able to access the source page | The renderer needs the supplied HTML/CSS and any referenced assets it must load |
| What does the next module need? | Check whether it accepts the screenshot output or a URL to it | Check whether it accepts the generated image file or URL |
These are practical distinctions based on the documented action descriptions, not claims about measured image quality or performance. Confirm that the target is accessible and the destination accepts the output you provide.
7. Troubleshooting
| Symptom | Likely cause | What to check or change |
|---|---|---|
| No title, description, or image appears in the lookup output | The page may not expose the corresponding Open Graph metadata, or the lookup response may differ for that target | Inspect the actual module output. Add a branch for missing fields and define a fallback instead of assuming every URL has metadata. |
| The lookup returns an image URL, but the download step fails | The URL may be inaccessible to the workflow, or the target may impose access controls | Check the resolved URL and response from the target. Confirm whether authentication is required and whether the URL is usable by the next module. |
| A shortened URL produces an unexpected result | The workflow may be passing the short link where a downstream action needs the final destination | Use Resolve URL and map its final URL into the following step. |
| An HTTPS request fails because of a certificate issue | Make rejects unverified self-signed certificates | Use a target with a valid, verified HTTPS certificate. Make’s HTTP app requires secure HTTPS. |
| The destination module rejects the image | It may require a file rather than a URL, or a URL rather than a file; it may also restrict formats | Check that module’s accepted input and map the correct output. Download the image if a file is required, or provide an accessible image URL if that is required. |
| The rendered card has missing content | A mapped field may be absent for some pages | Inspect run output and make the template or scenario handle optional values before rendering. |
| A page screenshot does not show the expected content | The source page may be inaccessible to the screenshot action, or its content may not be available in the captured result | Check the target page’s accessibility and whether a URL screenshot is the output you need. Use a designed card when the goal is a controlled layout from mapped metadata. |
8. Reliability, performance, and cost considerations
The research sources do not establish fixed processing times, costs, or performance guarantees for these Make actions, so estimate them with your own representative scenario and account. A scenario that looks up metadata, downloads an image, renders a card, and writes to a destination has more steps that can fail than one that only retrieves metadata. Use branches and error handling around optional metadata and inaccessible image URLs so one missing field does not silently produce an unusable result.
For reliability, test a mix of URLs: pages with metadata, pages without an image, redirecting links, and targets that require access. Confirm both the module output and the destination’s resulting image. For performance and cost planning, check the operations and service usage shown for your own account and workflow volume; no fixed benchmark follows from the documented module descriptions.
Or skip the browser setup
If you want a webpage screenshot without assembling browser capture infrastructure, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for request options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport 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}`);Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An 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. ScreenshotNeo can capture the page itself; use Make’s HTML/CSS to Image action when you specifically need a custom card from mapped metadata.
Sign up for 1,000 free screenshots a month, with no card required.
FAQ
Does Open Graph lookup create a new preview design?
No. It retrieves Open Graph information from a website. Use HTML/CSS to Image to render a custom card from a design you provide.
Can I use the page’s existing image in another Make module?
If the lookup returns an accessible image URL, download it when the next module requires a file. Check whether the destination accepts a file or a URL.
Which image formats can Make’s HTML/CSS to Image action produce?
Make lists PNG, JPG, and WebP as output formats.
Can every URL be processed?
No. A page may omit metadata, require authentication, or expose an image that the workflow cannot access. Build for those cases and check actual module outputs.
