ShrinkTheWeb API Response Formats: Image URL, Binary, and JSON
What the available ShrinkTheWeb documentation does—and does not—say about image URL, binary, and JSON responses, plus a practical screenshot API alternative.
The available ShrinkTheWeb documentation does not verify that its API offers image-URL, binary, and JSON response modes, or explain how to request them. It does not specify request parameters, response schemas, content types, or headers for those formats. Treat the three formats in this title as questions to verify against current first-party API documentation before writing code that depends on them.
The sources reviewed here are legacy Drupal integration guides and a Drupal.org project page. They describe using the service to generate, cache, and display screenshots, and show some capture settings. They do not establish the current behavior of the ShrinkTheWeb service or API. [Drupal.org ShrinkTheWeb project, Drupal 7 guide, Drupal 8 guide]
What is documented about ShrinkTheWeb
The Drupal module page describes a module that uses ShrinkTheWeb to cache and display website screenshots, such as page thumbnails. Drupal.org currently marks that module project unsupported and obsolete, reports no supported stable releases, and lists its last update as 2022-04-15. Those statuses describe the Drupal module project; they do not prove that the ShrinkTheWeb service or API is unavailable.
The Drupal 8 integration guide describes configuring access and secret keys, a local thumbnail cache folder, and cache duration. It shows integration-level capture settings such as specific-page capture, custom size, full-length capture, maximum crop height, viewport dimensions, delay after page load, and image quality. The guide states a quality range of 1 to 100 and notes that some features require an account upgrade. These are Drupal integration examples, not verified API response-format options.
The Drupal 7 guide, dated 2019-03-04, specifically says Drupal 7 is no longer supported. Both integration guides were last updated on that date. Treat them as historical guidance for those Drupal integrations.
Image URL, binary, and JSON: what remains unknown
The reviewed documentation does not establish whether these are supported ShrinkTheWeb response modes. It also does not provide the details needed to distinguish or implement them safely:
- Image URL: No verified parameter, URL field, expiration behavior, or image-hosting and caching details were found.
- Binary: No verified image-byte response, image content type, transfer behavior, or response headers were found.
- JSON: No verified JSON mode, field names, schema, embedded image representation, or error structure were found.
Do not assume a parameter name, endpoint, authentication method, content type, or payload shape based on the format labels alone. Confirm each one in current first-party API documentation or with the service provider.
How to verify a response format before integrating it
- Find current first-party API documentation. Confirm the endpoint, authentication method, supported request parameters, and the exact documented response mode. The Drupal guides are not API serialization references.
- Check the success response. Determine whether the body is a URL, raw image bytes, or structured JSON. Record the documented content type and any metadata or headers your application needs.
- Check errors separately. Establish how authentication failures, invalid URLs, capture failures, and rate or account limits are represented. Do not assume errors use the same format as successful responses.
- Test storage and delivery. If a response contains a URL, confirm its lifetime and access requirements. If it contains bytes, confirm the image format and save the response as binary. If it is JSON, validate its schema and determine how the image itself is delivered.
- Pin the assumptions in your integration. Add a small response-validation layer and handle unexpected status codes, content types, missing fields, empty bodies, and timeouts.
Choosing a response shape for your application
Because the available sources do not verify ShrinkTheWeb’s current modes, the following is a general integration decision guide—not a claim about what ShrinkTheWeb returns.
| Shape | Often useful when | Verify before relying on it |
|---|---|---|
| Image URL | Your app can display or pass through a remotely hosted image. | URL lifetime, access control, caching, and whether the URL is stable. |
| Binary image | Your service needs to store, transform, or serve the image itself. | Image format, content type, response size, and how API errors differ from image bytes. |
| JSON | Your app needs structured metadata alongside an image reference or other result details. | Schema, image location or encoding, error fields, and compatibility expectations. |
Whatever the provider returns, avoid treating every successful HTTP status as a valid image. Check the response type and body before storing or displaying it, and preserve enough error information to diagnose failed captures.
Options and configuration in the legacy Drupal guides
The Drupal 8 guide shows configuration at the integration level, including credentials, a local cache directory, and cache duration. Its rendering examples mention capture settings such as dimensions, full-page behavior, cropping, viewport size, delay, and quality. The documented quality range is 1–100. Some features require an account upgrade, according to the guide.
These details can help maintain an existing Drupal integration, but they do not define current API parameter names or response serialization. Check the relevant guide and your installed module version before applying them. The Drupal 7 guide is explicitly historical and says Drupal 7 is no longer supported.
Troubleshooting an integration
| Symptom | Likely cause | What to do |
|---|---|---|
| You cannot find documentation for an image-URL, binary, or JSON switch. | The reviewed Drupal documentation does not document API response modes. | Look for current first-party API reference or ask the service provider. Do not guess parameter names. |
| A Drupal example does not work in a direct API request. | The example may use Drupal module functions or integration-specific configuration. | Separate module configuration from API behavior and use current API documentation for direct requests. |
| The module status appears to say the service is unavailable. | The Drupal.org page marks the module unsupported and obsolete; that status is about the module. | Verify the service and API status with first-party service information. |
| A saved response is not a usable image. | The response may be an error or structured payload rather than image bytes; the expected format is unverified. | Inspect the HTTP status, content type, and a safely logged response excerpt. Avoid logging credentials or sensitive page data. |
| Captures differ in size or crop. | The Drupal 8 guide describes configurable capture dimensions, viewport, full-length capture, and crop settings. | Review the configuration used by the integration and verify the current service’s supported options independently. |
Performance, reliability, and cost considerations
The available ShrinkTheWeb sources do not provide current API latency, availability, pricing, response-size, or rate-limit figures. Do not infer these from the Drupal module’s cache settings or project status. For an application decision, verify current service terms and limits directly.
At the integration level, the Drupal 8 guide’s local thumbnail cache and cache duration illustrate that caching is a relevant concern for repeated thumbnail display. If you maintain such an integration, set cache behavior deliberately and account for stale images, capture failures, and storage cleanup. Those Drupal settings do not establish the service’s own caching behavior.
Or skip the browser setup
If your goal is to get a screenshot rather than investigate ShrinkTheWeb’s undocumented response modes, ScreenshotNeo provides a one-call screenshot API. Its documented endpoint returns a screenshot in PNG, JPEG, or WebP, or a PDF. See 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.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}`);ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots. Sign up for 1,000 free screenshots a month, with no card.
FAQ
Does the Drupal module’s obsolete status mean ShrinkTheWeb’s API is offline?
No. The cited status applies to the Drupal module project. The reviewed sources do not establish the current status of the service or API.
Are the Drupal 8 capture settings guaranteed to work in direct API calls?
No. The guide documents Drupal integration examples. It does not verify direct API parameter names or response behavior.
Can I safely choose one of the three named response formats from these sources?
No. The sources do not verify that the formats are available or describe their request and response details. Confirm them in current first-party API documentation before implementation.
