PNG or PDF — which format to pick
PNG gives you a pixel-for-pixel image of the page at the width you chose. Use it for visual review: comparing layouts, documenting UI states, generating thumbnails, checking how a redesign looks across pages. Files are large but lossless.
PDF produces a paginated document with selectable text and clickable links. Use it for deliverables: client reports, compliance archives, legal captures. One page per URL, all in the same ZIP. If your workflow involves a colleague opening the file and reading it rather than looking at it, PDF is the right call.
Choosing the right width
Three widths cover almost every use case. At 1440px you get the most common external monitor and high-resolution laptop viewport — the width where desktop layouts on most B2B and developer-facing sites look as intended. At 1280px you match common laptop screens and the standard "desktop" breakpoint in most design systems; use this when your project specifies a 1280px breakpoint and you want consistency with the design specs.
The 390px option is the iPhone 14 and 15 logical pixel width — the de-facto mobile audit standard. Google's mobile-first indexing uses a similar viewport. If you're checking how pages look for mobile users, 390px is the number to use. Not "mobile" as a vague concept.
The tool captures full-page height at whichever width you choose. A 390px capture of a page that's 6,000px tall at desktop will be 390px wide and whatever height the page reflowed to at that narrow viewport. (That can be quite tall — long-form content tends to grow significantly as text wraps and images stack at narrow widths.)
What you get in the ZIP
Each file is named after the domain and page path: example-com.png, example-com-pricing.png, example-com-docs-getting-started.png. For PDF format, the same naming applies with a .pdf extension. The ZIP contains one file per URL, skipping any that failed.
A summary file lists the result for each URL — success, timeout, or error — so you know which ones need a retry. Failed URLs don't cancel the batch; the rest process and download normally.
What happens with slow or broken pages
The renderer waits up to 30 seconds for each page. Sites that respond in that window but load slowly — large images, slow third-party scripts, render-blocking resources — will still capture, but the screenshot may show partially loaded content if scripts haven't finished when the capture fires.
Pages that time out, return HTTP errors (404, 500), or block headless browsers get marked as failed and excluded from the ZIP. The most common causes: bot detection that identifies headless Chrome by the User-Agent or missing WebGL fingerprint, pages behind authentication, and aggressive Cloudflare challenge pages.
If a URL consistently fails, try it in the above the fold checker — that tool uses the same renderer and will give you a clearer error message about what went wrong.
Who uses this tool and for what
The most common uses, roughly in the order we see them:
Agency deliverables are the most frequent — screenshot 5–8 competitor pages or client sites to drop into a strategy deck. Faster than manual tab-by-tab capture, consistent viewport size, downloadable in one click. QA after deployment is close behind: after pushing a release, grab screenshots of all affected pages at both desktop and mobile widths. A two-minute sanity check before marking the ticket done.
SEO and content audits fit naturally here: screenshot a list of landing pages at 390px to check mobile layout, or grab desktop captures at 1440px to document above-the-fold content before and after an optimization. Compliance and archival work well in PDF format — one file per page, text selectable, links clickable, ready for a legal archive or regulatory record.
Competitive monitoring is the other regular use case. Manually capture competitor pricing, feature pages, and homepages once a week. Low-frequency enough to work fine as a free tool; high-frequency monitoring belongs in the API.
When the free tool isn't enough
The free tool processes 10 URLs per batch. For larger lists — hundreds of pages, automated weekly captures, or webhook delivery — the ScreenshotRun API handles the same task with no URL limit and no UI required. You POST a list of URLs, set a webhook endpoint, and receive the files when rendering completes. The API call that powers this tool is:
GET /v1/screenshots/capture?url=https://example.com&format=png&width=1440&full_page=true
Batch the URLs in a loop or use the webhook parameter to chain the output directly into your storage or notification pipeline.
FAQ
Up to 10 URLs per batch in the free tool. Paste them one per line in the text area. For larger batches — hundreds or thousands of URLs — the ScreenshotRun API supports unlimited URLs with webhook delivery when each capture completes.
Typically 30–90 seconds for a batch of 10 pages, depending on page complexity and server response time. Pages with heavy third-party scripts or large images take longer. Full-page screenshots add time proportional to page height. The result panel shows individual timing for each URL once the batch completes.
Files are named after the domain and path of each URL — for example, example-com.png for the homepage, example-com-pricing.png for the pricing page. This makes it easy to match screenshots back to your URL list without renaming. For PDF batches, the same naming convention applies with a .pdf extension.
Failed URLs are skipped and excluded from the ZIP — they don't stop the rest of the batch from processing. A summary in the result panel lists which URLs succeeded and which failed, along with the reason (timeout, HTTP error, blocked by bot detection). You can retry individual failed URLs without re-running the whole batch.
Use 390 px to match the iPhone 14/15 logical pixel width — the most common premium mobile viewport as of 2026 and the width Google's mobile-first indexing crawler uses as a reference. It forces your pages to render at a realistic mobile viewport, including any responsive breakpoints that trigger below 430px.
No. The tool captures publicly accessible URLs only. Pages behind authentication return whatever a logged-out visitor would see — usually a login screen or redirect. For capturing authenticated pages, use the ScreenshotRun API with the cookies parameter to pass your session credentials.
Full page — the tool scrolls to the bottom of the page and captures everything, not just the initial viewport. A page that is 5,000px tall produces a 5,000px tall screenshot at the width you chose. If you only want the first screen (above the fold), use the above the fold checker instead.