The scenario almost everyone wants is the same one: a Google Sheet full of URLs, a screenshot of each, filed somewhere you can look at them later. Competitor pages, client sites, landing-page variants, a weekly visual record of things that matter to you.
Make does this in three modules and no code. The reason it has a reputation for being fiddly is a single wrong turn near the start — the HTTP module hands you a binary file, and the instinct is to convert it into something that looks more like a link. That conversion is what breaks, and the community threads about it are long.
You do not convert it. You map it.
The short answer
Use HTTP → Download a file to call the screenshot API, then map that module's output straight into a Google Drive, Dropbox, Gmail or Airtable module. Make treats the response as a native file — Make's file handling takes two inputs, "file name" and "data", and its docs confirm that "both binary files (such as photos, videos, and pdfs) and text formats are supported". The image never needs encoding, and there is no intermediate URL.
The scenario, end to end
Module 1 — Google Sheets → Search Rows. Point it at your sheet and, if you are re-running it, filter to rows where the screenshot column is still empty.
Module 2 — HTTP → Download a file. (In the older HTTP app this module is called Get a file, which is what most forum posts still say. Same thing.)
- URL:
https://api.site-shot.com/ - Query String parameters:
| Key | Value |
|---|---|
url |
mapped from the Sheets row |
userkey |
your API key |
full_size |
1 |
no_ads |
1 |
no_cookie_popup |
1 |
Rather than pasting the key into the parameter, put it in a keychain — the API Key type lets you choose whether the key goes in a header or the query string and lets you name the parameter, which is exactly what userkey needs. The key then lives in one place instead of in every scenario that uses it.
no_ads and no_cookie_popup earn their place immediately: without them a large fraction of your captures are a cookie consent dialog, which is a useless image you paid full price for.
Module 3 — Google Drive → Upload a file. Map the file from the HTTP module into it. Make's documentation describes this exact hop — you "map the downloaded file from the http > download a file module to the appropriate field in your" destination module, and the file name and content map across together.
Module 4 (optional) — Google Sheets → Update a Row, writing the Drive link back next to the URL so the sheet becomes the index.
Don't convert the binary
This is the part worth reading twice, because it is where the afternoon goes.
When the HTTP module returns an image, its output is binary data. It looks unreadable in the execution log, which is normal and correct. The instinct at that point is to reach for base64() or toString() to turn it into something that looks like a URL you can put in a spreadsheet cell.
That does not produce a URL. Base64 of an image is just the same image in a longer, text-shaped form — it is not a link, and no amount of further conversion makes it one. If what you need is a link, the file has to be uploaded somewhere that serves it: Drive, Dropbox, S3, your own storage. That upload is the step you are missing, not a conversion.
If what you need is the image itself — attached to an email, filed in Drive, pushed into an Airtable attachment — you skip conversion entirely and map the file across. That is the whole reason Make's file model exists.
One related setting: Parse response on the Make a request module is for structuring JSON and XML so the fields become mappable. An image body has nothing to structure. Leave it off, or use Download a file, which is built for this.
The 5 MB wall
Make caps the size of a file it will handle, and the cap is per plan. From its own documentation:
| Plan | Maximum file size |
|---|---|
| Free | 5 MB |
| Core | 100 MB |
| Pro | 250 MB |
| Teams | 500 MB |
| Enterprise | 1,000 MB |
On the Free plan, 5 MB is a live constraint for screenshots, not a theoretical one. A full_size=1 capture of a long modern landing page — hero video poster, a dozen sections, a fat footer — clears 5 MB without trying. The scenario fails at the file, not at the request, which makes it look like the API returned something wrong.
Three ways out, cheapest first: capture the viewport instead of the whole page, switch to format=jpeg on image-heavy pages, or cap the height with max_height. Details below.
Keeping the capture small
- Viewport instead of full page. Drop
full_sizeand passwidthandheight. For a weekly visual record, the top of the page is usually what you are actually comparing. max_heightputs a ceiling on a full-page capture that would otherwise run to twenty thousand pixels.format=jpegis meaningfully smaller on photographic pages. Keep PNG where the page is mostly text and UI — JPEG artifacts around small text are ugly and it is the text you are usually reading.
Every capture counts as one screenshot against your plan, however it was triggered.
Capturing from another country
Add a two-letter ISO 3166-1 country code to the query string and the render goes through a real IP address in that country, with the language, time zone and geolocation defaults that belong to it:
| Key | Value |
|---|---|
country |
DE |
strict_country |
1 |
Pass the two-letter ISO 3166-1 code — country=DE. The API does also resolve a full English name (country=Germany comes back parsed as DE, with German language and time zone), but a value it cannot resolve is not rejected — it falls through to a US render, so the code is the form to rely on.
strict_country=1 is the one to add deliberately. Without it, a country whose proxy pool is momentarily exhausted quietly falls back to a US render, and your scenario files a perfectly normal-looking screenshot of the wrong country into Drive. Nothing in the run history flags it. With it, the request fails fast — HTTP 404, in well under a second and with no render spent — the module errors, and you can see which rows to retry. Note that the readable "error": "country_unavailable" body only exists in response_type=json mode, and there it arrives with HTTP 200; in image mode the status is the whole signal.
If you are capturing ads or localised offers, this parameter is the difference between a record you can trust and one you cannot.
Geotargeting comes with any paid plan; the current country list is on the countries page and moves with live proxy capacity.
Where the honest limits are
You may not need Make for this at all. If the whole job is "capture this URL every day and keep the history", we do that ourselves — scheduled screenshots run on a cadence, file every capture in a dated library, and can email you when a page changes by more than a threshold you set. No scenario, no operations, no Drive folder. Make earns its keep when the screenshot is one step in a longer chain — into a CRM, a Slack message, a client report, a sheet other people read.
Every module run costs an operation. A Sheets iterator over 400 URLs with an HTTP call and a Drive upload is not 400 operations, it is 400 × the modules in the loop. Scenarios that felt free while you were testing on five rows do not stay free.
Pages behind a login will not capture. The API renders public URLs; a members-only page returns whatever a logged-out visitor sees.
Long pages need a longer timeout. The HTTP module's timeout is a field you can raise, and a slow, heavy page will need you to. If captures of one particular site fail while everything else works, that is the first thing to check.
The free browser tool has no API. site-shot.com captures any public page with no signup, which is the fastest way to see what a capture of your target looks like before you build the scenario. It is a browser tool, not a free API tier; the API needs a key, and plans start at $5/mo for 2,000 screenshots.
FAQ
How do I take a screenshot of a website in Make.com? Use the HTTP module's Download a file action to call a screenshot API, then map its output directly into a destination module such as Google Drive, Dropbox or Gmail. Make treats the response as a native file — its file handling takes a file name and data, and both binary files such as photos and text formats are supported — so the image needs no encoding step in between.
How do I convert the binary output of Make's HTTP module into a screenshot URL? You do not convert it. Base64 or text conversion produces the same image in a longer form, not a link. To get a URL you have to upload the file to storage such as Google Drive or Dropbox and use the link that upload returns; to use the image itself, map the file straight into the destination module without converting anything.
Why does my Make screenshot scenario fail on some websites but not others? The most common cause on the Free plan is the file size cap: Make allows a maximum file size of 5 MB on Free, and a full-page capture of a long page exceeds it. Capture the viewport instead of the full page, switch the format to JPEG, or cap the capture height. A slow page can also exceed the HTTP module's timeout, which is a separate field you can raise.
Where should I put my API key in Make? In a keychain rather than typed into each scenario. Make's API Key keychain type lets you choose whether the key is added to the request header or the query parameters and lets you name the parameter, which is what a key passed as a query parameter such as userkey requires.
Can Make take a screenshot from a specific country? Yes. Add a two-letter ISO 3166-1 country code such as DE to the query string to route the render through a real IP address in that country, and add strict_country so that an exhausted country pool fails the request outright with an HTTP 404 instead of silently falling back to a United States render. Geotargeting is included with any paid Site-Shot plan.
The free Site-Shot browser tool captures any public page with no signup — try one of your URLs before you build the scenario. For the API, plans and pricing start at $5/mo for 2,000 screenshots.