ShrinkTheWeb API Returns an Old Screenshot: How to Fix Caching
Trace a stale ShrinkTheWeb screenshot through Drupal, application storage, and delivery caches. Learn what the historical docs confirm—and what they do not.
Start by finding which layer is serving the old image. If you use the Drupal ShrinkTheWeb Screenshot Thumbnails integration, check its local thumbnail folder and cache-age setting first. Then compare the image stored or displayed by your application with a fresh capture obtained through current ShrinkTheWeb account documentation. Finally, check browser, CDN, or image-proxy caches. The available ShrinkTheWeb documentation describes Drupal-side caching, but does not establish a current API parameter or endpoint that forces an upstream refresh.
Do not assume that a freshness parameter documented by another screenshot provider works with ShrinkTheWeb. Confirm current request syntax in your account’s own documentation before changing API calls.
1. Identify which cache contains the old image
A screenshot can be stale at more than one point in its path. Diagnose each layer separately instead of repeatedly reloading the same page.
| Layer | What may be stale | How to check |
|---|---|---|
| Drupal module | A thumbnail stored in the module’s configured local folder, retained according to its cache-age setting. | Inspect the module configuration and locate the file Drupal actually serves. |
| ShrinkTheWeb service | The upstream capture associated with the requested page. | Use only a refresh method confirmed by the current ShrinkTheWeb account documentation. The historical Drupal instructions do not establish one. |
| Application or database | A copied screenshot or a URL/reference that still points to an older object. | Compare the application’s stored file and metadata with the upstream image you have verified. |
| Delivery layer | A browser, CDN, reverse proxy, or image proxy serving a previously cached response. | Inspect response headers and compare the public image URL with the underlying stored object, where your setup allows it. |
The cache-layer breakdown is diagnostic reasoning, not a claim that ShrinkTheWeb documents each of these layers. Different screenshot providers describe their own cache behaviors; those details cannot be assumed to apply to ShrinkTheWeb.
2. Check the historical Drupal module settings
The Drupal 7 and Drupal 8 ShrinkTheWeb setup pages were last updated on 4 March 2019. They describe a thumbnail folder for cached images and a setting for how many days cached images remain unchanged. If your installation uses this integration, inspect those values first: Drupal 7 setup and usage and Drupal 8 setup and usage.
- Open the ShrinkTheWeb module’s configuration page in Drupal. The historical Drupal 8 guide gives
admin/config/media/shrinktheweb; paths can differ by Drupal version and installation. - Check the configured thumbnail directory. Confirm it is the directory used by the displayed image and that Drupal can read it.
- Review the number of days cached images remain unchanged. A long interval can make an old local thumbnail appear to be an upstream refresh problem.
- Identify the specific thumbnail file associated with the page. Compare its modification time and contents with the image currently shown in the browser.
- If you change settings or replace a file, request the displayed image again and inspect whether the response is still coming from a downstream cache.
Those pages are historical instructions, not confirmation that the module remains compatible with current Drupal releases or that ShrinkTheWeb’s service currently supports a particular refresh workflow.
3. Check whether your installed module supports refresh
The Drupal project page describes a historical “Refresh ALL” feature intended to refresh and update screenshots across a Drupal site. Verify that your installed module release includes this function and understand what it refreshes before using it. Do not assume that a control documented for one release exists in another.
The project page also says the Drupal project appeared unsupported as of 31 January 2022. That warning concerns the Drupal module project; it does not prove that the ShrinkTheWeb screenshot service itself is unavailable. See the Drupal.org ShrinkTheWeb project page for the historical feature note and project status statement.
4. Compare the upstream capture with the image your site serves
Once you have confirmed a way to obtain a current capture using your account’s documentation, compare that result to the Drupal thumbnail and the public image response. This comparison narrows the problem:
- Upstream image is old: investigate the capture request and the current ShrinkTheWeb account documentation. The sources available here do not document a current force-refresh request parameter.
- Upstream image is current, Drupal file is old: focus on Drupal’s local thumbnail storage, configured cache age, and the installed module’s refresh behavior.
- Drupal file is current, public page is old: focus on application copies, browser caching, CDN rules, or image proxies between Drupal and the visitor.
- Different URLs show different versions: verify which exact URL the page uses, including query string, host, and image transformation path. A cache key can depend on the URL used by the delivery layer.
As provider-specific examples, ScreenshotOne documents that fetching its cache URL does not regenerate a capture, and ScreenshotEngine documents possible browser/CDN caching delays. Those examples illustrate why caches should be separated during diagnosis; they are not ShrinkTheWeb behavior claims. See ScreenshotOne’s caching documentation and ScreenshotEngine’s product documentation.
5. Avoid guessing a ShrinkTheWeb refresh parameter
The ShrinkTheWeb Drupal setup guides explain capture options and local cache settings, but the available evidence does not confirm a current upstream force-refresh endpoint or parameter. In particular, do not copy a parameter such as fresh, a TTL option, or a cache-busting convention from a competing service and send it to ShrinkTheWeb. Similar names do not imply compatible APIs.
If current account documentation provides a refresh operation, follow its exact endpoint, authentication, and cache semantics. If it does not, contact the service through the support channel available to your account rather than relying on old Drupal module behavior.
6. Troubleshooting common symptoms
| Symptom | Likely cause | What to do |
|---|---|---|
| The Drupal page keeps showing the same old thumbnail. | The module’s local thumbnail is within its configured unchanged period, or the page serves a stored file. | Check the configured cache age and thumbnail folder. Confirm which file and URL the page renders. |
| You cannot find “Refresh ALL.” | Your installed module version may not include the historical feature, or the control may differ by release. | Check the installed release against the Drupal project page and its documentation. Do not assume it is available. |
| The Drupal thumbnail file is new, but the browser still shows the old image. | A browser, CDN, reverse proxy, or image transformation service may retain a cached response. | Inspect the public response and cache headers; purge or revalidate the relevant delivery cache according to that system’s documentation. |
| A competing provider’s refresh parameter has no effect. | That parameter is not established as ShrinkTheWeb syntax. | Remove guessed parameters and confirm the request format from current ShrinkTheWeb documentation. |
| The module settings page is missing or errors. | The historical Drupal integration may not match the installed Drupal version, or the module may be unsupported. | Check module and Drupal compatibility before changing production configuration. Drupal.org’s project page carries an unsupported-project warning dated 2022-01-31. |
| Changing the local cache age does not update the image immediately. | The setting may govern future local reuse, while an already stored file or downstream cache still exists. | Trace the exact file and response path. Do not infer that changing the local setting forces a new upstream capture. |
7. Performance, reliability, and cost considerations
- Performance: Reusing local thumbnails can avoid repeated capture requests and reduce page work. Shortening a cache interval may increase refresh activity; the exact upstream request cost and limits must come from current ShrinkTheWeb account documentation.
- Reliability: A local copy can keep a page rendering when a remote capture is slow, but it also means the visible image may lag behind the source page. Track capture time or file modification time if freshness matters to your application.
- Storage: The Drupal guide lets administrators choose a thumbnail folder. Monitor that location as the number of captured URLs grows, and ensure backups and permissions match your deployment.
- Cost: No current ShrinkTheWeb prices or refresh entitlements are established by the sources used here. Check the account’s current plan and API documentation before increasing capture frequency.
- Operations: Record the requested page URL, the capture time you can verify, the stored asset path, and relevant cache headers. This makes it easier to pinpoint which layer served an old image.
8. Use a screenshot API with explicit capture behavior
If the legacy integration is difficult to maintain, consider a service whose current documentation clearly explains how captures and caches work. For example, ScreenshotAPI.net documents a fresh parameter and TTL behavior; that is specific to ScreenshotAPI.net and must not be used as ShrinkTheWeb syntax. ScreenshotOne documents that requesting its cache URL alone does not trigger a new render.
ScreenshotNeo is another option to evaluate: it provides a website screenshot API and MCP server. Its response identifies the page verdict and billing status; bot checks, blank pages, timeouts, failed loads, and cache hits are not billed. See the ScreenshotNeo API documentation for its request options and response details.
Or skip the browser setup
For a new capture workflow, ScreenshotNeo takes a URL in one GET request and returns an image or PDF. This example saves a WebP response:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpMore request options and formats are in the ScreenshotNeo documentation. ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, timeouts, failed loads, and cache hits are never billed. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Create a free ScreenshotNeo account and start with 1,000 screenshots a month, no card required.
FAQ
Does changing Drupal’s cache age force ShrinkTheWeb to make a new capture?
The historical Drupal guide describes how long locally cached thumbnails remain unchanged. It does not establish that changing this setting forces an upstream capture.
Is the ShrinkTheWeb service discontinued?
The cited Drupal.org warning says the Drupal project appeared unsupported as of 31 January 2022. It is not evidence that the screenshot service itself has shut down.
Can I add a timestamp query parameter to force a fresh ShrinkTheWeb screenshot?
The available sources do not confirm that technique or a current ShrinkTheWeb force-refresh parameter. Verify behavior with current service documentation before relying on it.
What should I record when investigating future stale images?
Keep the source URL, the asset URL or local path, the file’s capture or modification time, and relevant response cache headers. Those details help distinguish a stale capture from a stale delivery response.
