Website Screenshot Generator Free Tool

Enter a URL

About Website Screenshot Generator

What This Tool Actually Does

Paste a URL into the box above, submit it, and you get back one image: a screenshot of that page's top, generated by a separate third-party service and displayed inline on this page. There's exactly one field to fill in and exactly one thing that comes out of it. No viewport size to choose, no format to pick, no "full page" toggle, no download button. If you're expecting a settings panel, there isn't one here — this is a single-purpose hotlink, not a screenshot studio.

The image itself doesn't come from this site's own server. Submitting the form builds a URL pointing at thum.io, an independent third-party screenshot API that this tool has no ownership stake in, and drops that URL straight into an <img> tag. Your own browser is what actually fetches and displays the picture, the same way it fetches any other image on a webpage. This site's PHP code never touches the image bytes, never renders anything itself, and never stores a copy anywhere. It's a thin wrapper around someone else's free API, and that single fact explains almost everything else about how this tool behaves, including a couple of quirks covered further down.

What you get back, specifically, is a fixed 800×800-pixel PNG showing the top of the page as it currently renders — not the whole scrollable document, just what would be visible in a browser window before scrolling. That's confirmed by directly testing the exact endpoint this tool calls, not assumed from a spec sheet, and the full detail on exactly what that testing showed is a few sections down. For now, the short version: one URL in, one square top-of-page snapshot out, nothing configurable in between.

How the Screenshot Actually Gets Generated, Step by Step

Here's the real sequence, the way the code behind this page actually runs it, from the moment you hit submit to the moment an image appears.

1. Your input is validated first. Whatever you type is trimmed and checked with a standard URL validator after a scheme is added automatically for validation purposes. If it doesn't pass, the tool stops immediately with an "Input Site is not valid!" message, and nothing else happens — no request is built, no image is fetched.
2. No CAPTCHA gates this tool, but a site-wide burst limiter still applies. This specific tool has no CAPTCHA challenge in front of it — checkable directly in the site's own database, not an assumption carried over from a different tool. There's also no per-tool rate limit written into this tool's own code. What does exist, shared across every tool on this entire site including this one, is a background throttle that flags an IP if it fires more than 15 requests within the same one-second window, blocking that IP from further submissions for the rest of the day. Normal, manual use — checking one URL, looking at the result, checking another — never comes close to that threshold. That shared throttle is real and does apply to this tool, so "no rate limit at all" isn't quite accurate on its own.
3. Only the hostname is extracted from your input. Once validation passes, the tool parses out just the domain (say, example.com) and discards the rest of what you typed for the purpose of building the actual image request. A path or query string you included gets folded into that same hostname-extraction step, so the full URL, not just the bare domain, is what actually gets passed along to the screenshot service.
4. One image URL gets built, pointing at a third-party API. The tool constructs a single string: a request to thum.io's free hotlink endpoint, asking for an 800-pixel-wide capture of your submitted address. That's the entire "request" this tool makes. There's no additional configuration sent along with it — no delay parameter, no format flag, no full-page flag, no viewport-height flag. Whatever thum.io's own default behavior is for a bare width-only request is exactly what you get, because that's all this tool ever asks for.
5. One real quirk: the capture request always assumes HTTPS. Regardless of whether you typed http:// or https://, or whether the target site even serves a valid HTTPS connection, the actual image request hardcodes https:// in front of the extracted hostname. In practice this almost never matters, since the overwhelming majority of live sites today serve HTTPS by default. But if you're testing a genuinely HTTP-only target — an old internal tool, a staging server with no TLS certificate — this is a real edge case where the screenshot could fail to load even though the site itself is reachable over plain HTTP.
6. The image is rendered entirely on thum.io's servers, not this site's. This site's PHP code doesn't run a browser, doesn't execute JavaScript, and doesn't do any rendering work at all. It builds a URL string and hands it to your browser via an <img src> attribute. Your browser then makes its own separate request straight to image.thum.io, and whatever comes back from that request is what you see on the page.
7. There's no separate "screenshot failed" error message from this tool. Because this site's own code never fetches or checks the image itself, it has no way to know whether thum.io's request actually succeeded. If the target URL is genuinely broken or thum.io can't reach it, what you'll see is a plain broken-image icon in your browser — the same thing you'd see for any dead image link on any webpage — not a custom error banner from this tool. The one error message this tool CAN show you is the input-validation one from step one, for a URL that never made it past the initial check.
8. Your own browser can also cache the result, separately from thum.io's own caching. Once your browser has loaded an image from a particular URL, it may reuse that cached copy on a quick repeat visit rather than fetching it again, the same way it would cache any other image on the web. If you're trying to force a genuinely fresh capture after a site changes, a hard refresh of this results page (bypassing your own browser's local cache) is worth doing in addition to resubmitting the form, since two separate caching layers, your browser's and thum.io's, can each independently hand back an older copy.

Validate the input, extract a hostname, build one hotlinked image URL pointing at a separate company's free API, let the browser do the rest, that's the entire flow. There's no crawl, no multi-step rendering pipeline on this site's own servers, and, contrary to what the previous version of this page implied, no configurable options anywhere in that sequence.

How to Use This Tool

1. Open the page and find the input box. It's a single text field asking for a URL; you can include https:// or leave it off, since the tool handles either.
2. Type or paste the address of the page you want a screenshot of. Use the exact page you care about, including any specific path, not just the bare domain, since a screenshot of a homepage and a screenshot of a deep inner page are two different things.
3. Submit the form. There's no preview step and no settings to configure first — one submission gets you one result.
4. Wait for the image to load. Since the picture is fetched from a separate third-party server rather than generated locally, it can take a moment to appear, especially the first time a given URL is requested (more on why in the next section).
5. If the image doesn't appear at all, try resubmitting the exact same URL once. A genuinely broken link produces a broken-image icon rather than any content; a URL that simply hasn't been captured recently by the underlying service sometimes needs one more try before the real picture shows up.
6. Save the image the same way you'd save any picture from a webpage. There's no built-in download button, so right-click (or long-press on mobile) and use your browser's own "save image" option if you want to keep a copy.

What You Actually Get Back: Format, Size, and the "Processing" Placeholder

Rather than guess at how the underlying service behaves, the exact endpoint this tool calls was tested directly. Here's what that testing actually showed, stated as tested fact, not assumption.

This tool returns a fixed-size, viewport-style snapshot of whatever's visible at the very top of a page, in PNG format, with no option to change any of that. It is not a full-page capture: a long landing page, a lengthy article, or a scrolling documentation site will only ever show the portion that would be visible before scrolling, cropped into an 800×800 square.

The "processing" placeholder behavior can look like a bug the first time you see it, so here's what's actually happening: the underlying screenshot service renders pages on demand and appears to cache the result for a while afterward. When a URL genuinely hasn't been requested through that service recently, the very first hit can return a temporary placeholder graphic rather than your target page, while the real capture happens in the background. Submitting the same URL again a little later — the same short wait tested directly above — reliably returns the actual screenshot instead. This isn't specific to any site being screenshotted; it's a general behavior of how the underlying free tier works, and it's the most common reason a first attempt looks wrong while a second attempt, seconds later, looks correct.

Correcting the Old Description of This Tool

This section exists because the previous version of this page described a tool that doesn't exist. It described a settings-rich, headless-browser screenshot generator with a viewport-size picker (desktop/tablet/mobile presets or custom width and height), a toggle between full-page and viewport-only capture, an adjustable render delay for pages that load content asynchronously, a choice between PNG and JPEG output, and a download button that returned a file. None of that is real. This tool, as it actually exists right now, has a single URL field and a single fixed-size image as output, with no picker, no toggle, no delay setting, no format choice, and no download button anywhere in its interface or its underlying code. That's not a minor inaccuracy to quietly smooth over — it's a wholesale mismatch between the feature list a reader was shown and the tool they'd actually land on, corrected here rather than carried forward.

There's a second, separate correction, about how the screenshot itself gets generated rather than what options exist around it. Before mid-2026, this exact tool ran on a different backend entirely: a paid, license-key-gated third-party vendor, accessed through a token-and-session handshake, with a "Download High Quality Image" button that served a cached image file from this site's own server. That vendor is confirmed dead as of a code change dated 2026-07-19, and the token/session code plus the download button were removed from the live template along with it. The tool now works the simpler way described throughout this page: a direct hotlink to a free third-party API, with no server-side caching or download step on this site's end at all. If you used this tool before that date and remember a "download" option, that memory is accurate — it existed, and it's gone now, replaced by the leaner, hotlink-only version currently live.

Both corrections point the same direction: fewer moving parts than the old copy implied, and less than what the old copy implied even at the level of the screenshot's source. Anyone comparing this tool against that older description should treat the version on this page, tested directly against the live code and the live third-party endpoint it calls, as the accurate one.

What This Tool Is Actually Useful For

Given a fixed-size, top-of-page-only, no-frills screenshot with no configuration, there's still a real, honest set of situations where that's exactly enough.

A fast visual sanity check

Sometimes the only question is "is this thing actually up, and does it look roughly right?" — not a pixel-perfect audit, just a quick glance to confirm a site isn't showing a maintenance page, a broken layout, or a blank white screen. A single top-of-page screenshot answers that question in a couple of seconds without you having to open a new tab and navigate there yourself.

A rough placeholder preview image

Pages that lack a properly configured Open Graph or social-preview image sometimes need a stand-in fast — a rough visual reference for a document, a chat message, or a quick internal note, where "close enough" beats "nothing at all." A fixed 800×800 top-of-page capture works fine for that kind of low-stakes placeholder use, though it's not a substitute for a properly designed, purpose-built preview image on anything customer-facing.

A glance at a competitor's current homepage

Checking what a competitor's landing page currently looks like above the fold, without visiting the site directly yourself, is a reasonable use of a single fixed-size snapshot — understanding clearly that it's one square crop of the top of the page, not a full record of everything below the fold, and not something to build a detailed design comparison on.

Confirming a domain actually resolves to a live site

Alongside a DNS or hosting lookup, a quick screenshot attempt is a fast, informal way to confirm a domain is pointed at something real rather than a parked page or a dead server — if a screenshot renders actual page content rather than a blank canvas or a parking-page template, that's a reasonable, if informal, signal the domain is live and serving something.

How This Compares to Taking Your Own Screenshot or Using a Full Screenshot API

There's more than one way to get an image of a webpage, and it helps to see where this specific tool actually sits among the options rather than treating it as the only choice.

The tradeoff runs in a clear direction: this tool wins on convenience, since there's genuinely nothing to set up and no account to create, but it gives up nearly every kind of control in exchange for that simplicity. A manual browser screenshot gives you more control over what's visible on screen at the moment you take it, at the cost of doing it by hand every single time. A dedicated screenshot API gives you the most control of the three, at the cost of actually needing to sign up for one and, usually, wire it into whatever workflow you're using. Which of the three is worth reaching for depends entirely on whether "one quick glance" is genuinely all you need, or whether the job actually calls for repeatable, configurable, automatable captures.

Limitations: What This Tool Can't Do

What this specific tool doesn't offer matters more to spell out here than usual, given how much the old copy overstated its capabilities.

• No custom size, ever. Every result is the same fixed 800×800 square. There's no way through this tool's interface to request a wider capture, a taller one, or a specific mobile/tablet resolution.
• No full-page capture. Only the very top of a page is ever shown. Anything below the initial visible area, on any page longer than the fixed capture height, simply isn't in the image at all.
• No format choice. Every result comes back as a PNG. There's no JPEG option, and no way to request one.
• No render-delay control. Pages that load content asynchronously — a lazy-loaded hero image, a cookie-consent banner that fades in a second or two after the page loads, a chat widget that pops up after a short delay — may or may not have finished appearing by the moment the capture actually fires, and there's no setting here to wait longer for them.
• No download button. The image is a hotlink displayed inline on this page. Getting a saved copy means using your own browser's built-in "save image" function, the same way you'd save any other picture on any other webpage.
• No authenticated/logged-in captures. The underlying service has no session or cookies for the target site, so a page that requires login will typically show up as its logged-out state — most often a login screen rather than whatever's actually behind it.
• Sites with bot-detection may block or degrade the capture. The rendering happens through an automated visitor on the third-party service's end, and some sites deliberately detect and block that kind of automated traffic, which can produce an incomplete or fallback-page result that has nothing to do with this tool itself.
• A "cold" request can return a placeholder instead of real content. As covered above, a URL that hasn't been captured recently can briefly return a generic processing graphic instead of your target page on the very first try.
• HTTPS is always assumed for the actual capture request. A genuinely HTTP-only target, with no valid HTTPS listener at all, is a real, if uncommon, edge case where the screenshot could fail to load even though the underlying site is reachable over plain HTTP.
• The shared site-wide submission throttle still applies. Same background limiter as every other tool on this site: more than 15 requests from one IP within the same one-second window trips a same-day block. Normal spaced-out use never approaches it.

Deciding Which of the Three Options Actually Fits Your Situation

None of the limitations covered above are a criticism of a free, single-purpose tool, they're just boundaries worth knowing before relying on it for something it was never built to do. Using the comparison above as a starting point: if the job is a one-off glance, this tool or a manual browser screenshot both work fine, and the manual route only pulls ahead when you specifically need to control window size or scroll position yourself. If the job repeats, say, checking the same set of pages every week, or needs to run unattended as part of a larger process, that's the point where a dedicated screenshot API earns its setup cost, because none of the free, no-signup options here are built for repeatable automation.

This free tool isn't going to grow into something it isn't. For a quick, no-signup, no-configuration glance at the top of a page, confirming it's up, checking it looks roughly right, or grabbing a rough placeholder image, it does that one job fine. It's simply not the right reach the moment the actual need is control over size, format, timing, or a full scroll-through capture.

Reading a Result That Looks Wrong

A few scenarios come up often enough to walk through directly, each with a specific, checkable reason behind it rather than a shrug.

The image shows a spinner and a logo instead of the site

That's the cold-start placeholder covered above, not an error on this tool's end. Wait roughly half a minute and resubmit the exact same URL; the real capture almost always shows up by the second try.

The image shows a cookie banner or a first-visit popup you don't normally see

Because the capture behind this tool has no saved cookies or browsing history for the target site, it's treated as a brand-new visitor every single time, the same way a private/incognito browser window would be. Consent banners, first-visit modals, and newsletter popups that a returning visitor's browser would normally suppress can show up in the capture for exactly that reason.

The screenshot looks completely different from what you see visiting the same page yourself

Two realistic causes: either you're comparing a fresh, logged-out, cookie-less view against your own logged-in or previously-visited state of the same page (see above), or the page itself serves different content to different visitors, geo-targeting, A/B tests, or personalization can all mean two requests to the identical URL genuinely render differently, independent of anything this tool does.

Nothing loads at all, just a broken-image icon

That means the underlying request to thum.io failed outright, most likely because the target URL itself is unreachable (a typo, a dead domain, a server that's actually down) or because the target site's own bot-detection blocked the automated request. Try loading the exact URL directly in your own browser first to rule out a simple typo or a genuinely offline site.

Related Tools

A single top-of-page screenshot is often more useful paired with a couple of other quick checks than as a standalone verdict on a page.

• Website Source Code: if a screenshot shows something unexpected — odd formatting, missing content, a layout that doesn't look right — this tool lets you look directly at the raw HTML behind it, rather than guessing from the picture alone.
• Website Speed Checker: a page can look fine in a screenshot and still be slow to actually load for a real visitor. Pairing a visual glance with an actual load-time check covers two different, equally real concerns.
• Web Archive Cache Checker: this tool only ever shows you a page as it looks right now. If you want to see how the same page looked at an earlier point in time, that's a job for a historical archive lookup instead.

Frequently Asked Questions

Can I choose the screenshot size or capture the full page instead of just the top?

No. This tool always returns a fixed 800×800-pixel image showing only the top of the page, with no setting to change the dimensions or capture the full scrollable document. If you need a custom size or a genuine full-page capture, that's a job for a different, more configurable screenshot tool.

Why did my screenshot come back as a generic logo instead of my page?

That's a temporary "processing" placeholder from the third-party service this tool uses, and it typically appears on the very first request for a URL that hasn't been captured recently. Resubmitting the exact same URL a little later usually returns the real screenshot once the underlying render finishes.

Is there a download button for the screenshot?

No, there isn't one currently. An older version of this tool did include a download button tied to a since-removed backend, but the current tool displays the image inline only. Save it the same way you'd save any other picture from a webpage — right-click or long-press and choose your browser's save-image option.

Does this tool capture pages that require a login?

Not meaningfully. The underlying capture has no saved session or cookies for the target site, so a page gated behind a login typically shows up in its logged-out state, most often a login screen rather than whatever's actually behind it.

Why does this tool only ask for a URL, with no other options?

Because that reflects how the tool actually works: it hands your URL to a free third-party screenshot service and displays whatever comes back, with no configuration layered on top. An earlier version of this page described a richer set of options (viewport presets, a full-page toggle, a render delay, a format choice) that never actually existed in this tool's real code — this page has been corrected to match what's genuinely here.

Is there a limit on how many URLs I can check?

There's no CAPTCHA or per-tool waiting period on this specific tool, so checking a handful of URLs back to back works fine. A shared background throttle across every tool on this site does flag an IP that fires more than 15 requests within the same single second, but normal, spaced-out use never comes close to that.