ScreenshotNeo

BlogHow-to

How to Make Website Thumbnails for a No-Code Tools Directory

Build consistent website thumbnails for a no-code tools directory with Playwright or a screenshot API, plus practical guidance on cropping, storage, and refreshes.

By the ScreenshotNeo team4 October 20269 min read

To make website thumbnails for a no-code tools directory, capture each public landing page at the same documented viewport, then apply one consistent crop and image format. Use viewport screenshots for compact first-screen previews; use full-page captures only if your card design can show a long page legibly. Store your own durable copy with the source URL and capture date, and refresh it deliberately.

For a code-managed workflow, Playwright can capture a page, a selected element, or the full page, saving a file or returning a buffer for image processing. If you would rather avoid running browser infrastructure, ScreenshotNeo provides a screenshot API and MCP server for developers.

1. Decide what the thumbnail should show

Set the card design before capturing sites. There is no universally established thumbnail size or aspect ratio for directories; choose dimensions based on your card layout and how much of each page you want readers to see.

  • Viewport capture: shows the first screen at a chosen browser viewport. This is usually easier to recognize in a small card.
  • Full-page capture: includes the full scrollable page. Long pages can become too small to read when scaled down, so use this when the overall page structure is useful to the directory.
  • Element capture: captures a particular element, such as a product preview, if a stable selector identifies the part you want.

Pick a fixed display aspect ratio and a crop rule. For example, decide whether each source image fills the card and gets cropped, or fits entirely with possible empty space around it. Apply that same choice to every entry. The target dimensions should follow your design and delivery needs; they are not a published standard.

2. Capture with Playwright

Install Playwright and its Chromium browser, then save this as capture.mjs. It captures the first viewport of each URL at one fixed viewport and writes PNG files. Replace the example URLs with the public landing pages in your directory.

npm install playwright
npx playwright install chromium
// capture.mjs
import { chromium } from 'playwright';
import { mkdir } from 'node:fs/promises';

const urls = [
  'https://example.com',
  'https://example.org',
];
const outputDir = './thumbnails';
const viewport = { width: 1440, height: 900 };

await mkdir(outputDir, { recursive: true });
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({ viewport });
const page = await context.newPage();

for (const [index, url] of urls.entries()) {
  try {
    const response = await page.goto(url, {
      waitUntil: 'domcontentloaded',
      timeout: 45_000,
    });
    // Allow a short, explicit render interval; adjust for your sites.
    await page.waitForTimeout(1500);
    await page.screenshot({
      path: `${outputDir}/${String(index + 1).padStart(3, '0')}.png`,
      fullPage: false,
      animations: 'disabled',
    });
    console.log({ url, status: response?.status() ?? 'no response' });
  } catch (error) {
    console.error(`Capture failed for ${url}:`, error.message);
  }
}

await browser.close();

This example uses a single page sequentially, fixed browser viewport, a render pause, and per-URL error handling. The timeout is an operational choice, not a guarantee that every site will finish loading in that period. A navigation response can also be absent for some navigation patterns; record failures and review them instead of silently publishing a broken image.

Full-page and element captures

For a full-page image, set fullPage: true. For a specific element, locate it and call screenshot on the locator. Selectors are site-specific, so verify that the target exists and is the desired region.

await page.screenshot({ path: 'full-page.png', fullPage: true });

const preview = page.locator('main .product-preview');
await preview.waitFor({ state: 'visible', timeout: 10_000 });
await preview.screenshot({ path: 'product-preview.png' });

To process an image later rather than write it immediately, Playwright can return screenshot bytes as a buffer:

const imageBuffer = await page.screenshot({ type: 'png' });
// Pass imageBuffer to your image-processing or storage code.

Playwright documents page, full-page, and element screenshots, including file and buffer output in its Screenshots guide.

3. Make captures consistent and predictable

Use the same browser version, operating system or container image, viewport, device scale factor, and capture settings for each run. Playwright warns that rendering can vary with host OS, browser version, settings, hardware, power source, and headless mode. Keep your capture environment stable if you want comparable thumbnails. See Playwright’s visual comparison guidance.

Timing and changing page content

Choose a readiness rule that suits your directory. Waiting for the page’s initial DOM is often faster than waiting for every network request to stop, since analytics and other long-lived requests may continue. A fixed delay can help with client-rendered content, but it is not a universal readiness signal. For important entries, wait for a page-specific selector or inspect the output before publishing.

Animations, rotating banners, cookie notices, newsletter popups, chat widgets, hover states, and personalized content can change what appears in an image. Decide whether to preserve or suppress each kind of content, and use the same policy across the directory. Playwright’s visual comparison documentation shows how a stylesheet can hide volatile elements during captures. Avoid hiding a site’s content in a way that changes the meaning of the preview.

Crop and encode the same way

After capture, use one crop or fit rule for all entries, then encode consistently. PNG, JPEG, and WebP are common choices; choose based on the visual result and your storage and delivery needs. Check small text and fine edges at the actual card size. No one quality setting is established as right for every directory.

4. Store the image and refresh it deliberately

Save the image in storage controlled by your directory rather than relying on a temporary capture URL. Keep a record containing at least the listing identifier, source URL, capture time, viewport, capture mode, output format, and capture status. This makes it possible to identify stale or failed thumbnails and reproduce a capture later.

Refresh when a listed product changes its site or on a schedule that matches how often your directory needs current previews. The reviewed documentation does not establish a standard refresh interval. You can also refresh after a user reports a stale preview, while keeping the previous image available until its replacement is reviewed.

If you use a third-party screenshot API, check how long its output URLs remain available and download or cache images you need to retain. For example, OpenGraph.io’s API documentation says its generated screenshot URLs expire after 24 hours.

5. When an API is a better fit

Use browser automation when you want capture logic integrated with your own image-processing and storage workflow. Consider a screenshot API when you prefer URL-based capture and do not want to manage the browser setup yourself. Compare options by integration effort, batch volume, viewport and selector control, full-page support, output format, output durability, and how much capture infrastructure you want to operate.

ScreenshotNeo is the first API to try: it removes cookie banners, newsletter popups, and chat widgets before capture, bills only clean shots, and its paid plans start at $5 for 3,000 screenshots.

Or skip the browser setup

Make a screenshot with one GET request; change the target URL to the listing you want to capture. The examples and additional options are in 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 import('node:fs/promises').then(({ writeFile }) => writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

ScreenshotNeo accepts cookie and consent banners as a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 screenshots each month with no card; paid plans start at $5 for 3,000, and every feature is on every plan.

Get 1,000 free screenshots a month with no card.

Troubleshooting

Symptom Likely cause What to do
Navigation times out The site is slow, keeps requests open, or blocks automated traffic. Choose a suitable navigation readiness condition, wait for a specific visible element, and set a timeout that matches your job budget. Record the failure and retry selectively.
Image is blank or mostly empty The page needs client-side rendering, a longer render interval, or a required interaction. Wait for the main content selector, inspect the page state, and use a deliberate delay only when necessary. Check whether a login wall or bot check prevents the public page from rendering.
Cookie notice covers the preview The site presents a consent banner on a fresh browser session. Decide whether the directory should show the banner. If not, handle consent in a controlled way or use a capture option that removes consent overlays; verify that the underlying page remains representative.
Captures look different between runs Browser environment, dynamic content, animation, personalization, or timing changed. Pin the browser and runtime environment, use a consistent viewport and settings, and hide or wait for known volatile regions where appropriate.
Element screenshot fails The selector is incorrect, the element is not attached, or it is not visible. Confirm the selector against the current page and wait for the element to be visible before capturing. Provide a page-level fallback when a site redesign removes the target.
Thumbnail is unreadable in the card A full page or a poorly chosen crop was reduced too much. Try a viewport capture, adjust the card ratio, or use a crop that emphasizes the recognizable top section.
Saved API link stops working The provider’s image URL is temporary. Download the result into storage you control and serve that durable copy.

Performance, reliability, and cost

  • Throughput: browser launch and page navigation take work. Reusing a browser process and processing a controlled number of pages at a time can reduce repeated setup, but monitor memory and isolate failures so one page does not halt the batch.
  • Reliability: treat each URL as an independent job. Store status, capture time, and errors; retry transient failures selectively; and inspect images before they become directory cards. Do not assume every public URL will render successfully.
  • Consistency: a fixed viewport alone does not make captures identical. Keep the rendering environment and page readiness policy consistent as well.
  • Cost: a self-managed Playwright process has infrastructure and engineering costs even when the software itself is open source. An API trades some infrastructure work for provider pricing and constraints. The research sources do not provide comparative API pricing or service-level guarantees.
  • Storage and delivery: smaller encodings reduce storage and transfer needs but can make text or edges look worse. Review the real card display size and retain an original if you expect to revise crop rules.

FAQ

Should a directory use full-page thumbnails?

Only if readers benefit from seeing the page’s overall length or structure. A first-viewport image is often clearer at small card sizes; long pages shrink their content when fit into the same card.

Can I use a website screenshot just because the page is public?

Public accessibility alone does not settle whether copying, storing, or displaying a screenshot is permitted. Check applicable site terms and obtain legal advice for the jurisdictions and use case involved.

How often should thumbnails be refreshed?

Set the interval based on how current the directory needs to be and how often listed sites change. The reviewed sources do not establish an industry-standard interval.

Can screenshots prove that a product’s interface is current?

No. Keep the preview alongside the listing name and destination, and record when the image was captured. A thumbnail is a visual preview, not evidence that the current live interface is unchanged.