Urlbox Pricing Explained: API Plans, Credits, and Limits
Compare Urlbox’s advertised plans, understand how successful renders and render credits affect usage, and estimate which limits fit your workload.
Urlbox’s advertised plans range from Lo-Fi at $19/month for up to 2,000 renders to Enterprise plans starting at $3,000/month. The allowance is measured in successful renders, not simply API requests: a render can consume multiple units depending on duration, file size, and selected features. To choose a plan, estimate render consumption, then check request rate, timeout, output size, and the support or SLA terms your workload needs.
The figures below come from Urlbox’s pricing and API documentation, checked on October 3, 2026. Prices and service terms can change, so confirm them on the Urlbox pricing page before buying. They are vendor-published terms, not independent performance measurements.
1. Urlbox plans and advertised limits
Urlbox lists these monthly plans and included render volumes:
| Plan | Advertised price and allowance | Request rate | Timeout | File-size limit |
|---|---|---|---|---|
| Lo-Fi | $19/month; up to 2,000 renders | 30 requests/minute | 30 seconds | 2.5 MB |
| Hi-Fi | $49/month; up to 5,000 renders | 60 requests/minute | 90 seconds | 10 MB |
| Ultra | $99/month; up to 15,000 renders | 250 requests/minute | 300 seconds | No limit listed |
| Business | $498/month advertised; pricing text says $495 base plus $3 per 1,000 renders; table lists 1,000+ successful renders | 1,000 requests/minute | 300 seconds | No limit listed |
| Enterprise | From $3,000/month; custom limits and features | No limit listed | No limit listed | No limit listed |
The pricing page advertises a 7-day trial without a credit card for Lo-Fi, Hi-Fi, and Ultra, and a three-month Business trial on application. Prices exclude VAT at the prevailing rate. Business and Enterprise include advertised support, security, and SLA options, including 99.95% and 99.99% uptime SLAs respectively. Enterprise limits and pricing are custom. Treat these as Urlbox’s published commercial terms, not audited availability guarantees. Source: Urlbox pricing.
2. What a render credit means
Urlbox’s pricing page uses the terms “renders” and “Successful Renders Included.” It defines a successful render as one that returns an image and says failed requests are not charged. This does not mean every request that succeeds consumes exactly one render.
Urlbox’s pricing footnote says render consumption can increase based on the job:
- One render for each 30-second period taken to render.
- One render for each 5 MB of output file size.
- One additional render per year of Certified Archive storage.
- Twice the renders when GPU acceleration is used.
- Potential additional renders for advanced features.
For example, a successful request that takes longer than 30 seconds or produces a large file may use more than one render. A simple request count therefore understates usage for some workloads. The precise total depends on render time, output size, and enabled options; do not assign every request a universal per-request price. Check your account usage and response information against the current pricing terms. Source: Urlbox pricing.
Requests and renders are different counters
A request is an API call. A render is the unit that counts toward the plan allowance. One API request may use multiple renders, while a failed request is not charged according to Urlbox’s definition. Cached render links and REST API requests also behave differently; see the caching section below.
3. Estimate the plan your workload needs
- Forecast successful jobs. Count expected successful outputs in a typical month, separating images, PDFs, videos, or other outputs if their workloads differ.
- Account for multipliers. Review expected render duration, output size, GPU acceleration, archive storage, and advanced features. Add a safety margin for variability rather than assuming one render per request.
- Check throughput. Compare peak requests per minute with the plan ceiling. If jobs arrive in bursts, a monthly allowance alone will not prevent rate limiting.
- Check job limits. Match the listed timeout and file-size cap against your slowest pages and largest expected outputs.
- Decide what operational support is required. If you need an advertised SLA, security terms, or custom limits, compare the Business and Enterprise options directly with Urlbox.
- Revisit actual usage. Use response headers and account usage to refine the estimate after deployment.
As a rough planning model, calculate expected successful jobs × estimated renders per job, then compare that render estimate with the included allowance. This is a forecasting aid, not a price quote: Urlbox says consumption can depend on duration, size, and features, and Business has volume pricing. Confirm the current billing details with Urlbox.
4. API behavior that affects cost and limits
Urlbox documents a synchronous endpoint at POST /v1/render/sync. It accepts a publicly accessible url or supplied html. Its API reference lists PNG, JPG, WebP, PDF, SVG, MP4, WebM, and Markdown output formats, and documents project secret-key Bearer authentication. A synchronous response includes a temporary renderUrl that expires after 30 days. If a request is still running after 95 seconds, the endpoint returns a 307 redirect with a temporary continuation URL. See the Urlbox API reference.
The exact request schema and required options depend on the output and project configuration. Use the API reference for the current payload shape and authentication details; do not assume a render-link URL and the REST endpoint share identical caching or billing behavior.
REST API renders and cached render links
Urlbox says REST API requests are not cached or deduplicated: repeating the same REST call creates another render. Render links can cache screenshots for 30 days by default, with a configurable TTL or a force option. The pricing FAQ says a cached screenshot served from cache does not count against the monthly quota; the first render and REST API renders do count. Choose the mechanism based on whether you need a fresh render per API call or a reusable cached image. REST API versus render links, Urlbox pricing.
5. Monitor usage and request rate
Urlbox documents these response headers for render usage: x-renders-used, x-renders-allowed, and x-renders-remaining. It also documents rate-limit headers including x-ratelimit-limit and x-ratelimit-remaining. Log them with request IDs and outcomes so your team can distinguish monthly render consumption from short-term rate pressure. See Urlbox’s usage documentation.
The pricing page says it sends usage alerts at 80%, 90%, and 100% of monthly quota. It also says service is not cut off at quota overrun: Urlbox automatically upgrades to the next tier, with volume pricing. Treat that as a billing behavior to verify against your account terms before production usage. Source: Urlbox pricing.
6. Choosing among plans
| Workload condition | What to compare |
|---|---|
| Low volume, modest pages | Lo-Fi’s 2,000-render allowance, 30 requests/minute, 30-second timeout, and 2.5 MB cap. |
| General production rendering | Hi-Fi’s 5,000 renders, 60 requests/minute, 90-second timeout, and 10 MB cap. |
| Higher throughput or longer jobs | Ultra’s 15,000 renders, 250 requests/minute, 300-second timeout, and no listed file-size cap. |
| Business-critical workload | Business pricing mechanics, 1,000 requests/minute, 300-second timeout, support, security, and SLA terms. |
| Custom limits or contractual needs | Enterprise’s custom scope, price, limits, security, and service terms. |
These are practical comparisons of published limits, not claims that one tier renders faster or more accurately. Urlbox positions Lo-Fi for lower-cost thumbnails and social images, Hi-Fi for general rendering accuracy, Ultra for more complex cases, Business for business-critical applications, and Enterprise for custom solutions. Match the published plan terms to measured workload needs rather than treating that vendor positioning as an independent benchmark.
7. Troubleshooting pricing and limit surprises
Usage rises faster than the number of API calls
Cause: A render may consume multiple units because of duration, file size, GPU acceleration, archive storage, or advanced features.
Fix: Compare request counts with x-renders-used and x-renders-remaining; inspect job duration, output size, and enabled features before projecting monthly cost.
A repeated request consumes usage again
Cause: REST API requests are not cached or deduplicated according to Urlbox’s documentation.
Fix: If reuse is acceptable, evaluate render links and their cache TTL. Account for the first render and confirm whether subsequent requests are cache hits.
Requests are throttled even though monthly renders remain
Cause: The plan has a per-minute request limit independent of monthly render allowance.
Fix: Read x-ratelimit-limit and x-ratelimit-remaining, pace bursts, and retry transient rate limits with bounded exponential backoff and jitter.
A render exceeds the timeout
Cause: The page or output takes longer than the plan’s listed timeout, or the synchronous request continues beyond the endpoint’s 95-second behavior.
Fix: Check the plan timeout and API response. For the documented 307 continuation behavior, follow the temporary continuation URL as described by the API reference. Reduce unnecessary page work or choose a plan with an appropriate listed timeout.
A large output fails or is not accepted
Cause: The plan’s file-size cap may be lower than the resulting output; Lo-Fi lists 2.5 MB and Hi-Fi 10 MB, while higher tiers list no cap.
Fix: Reduce output dimensions or complexity where possible, verify the actual response size, and compare it with the current plan terms.
The invoice is higher than a simple plan division suggests
Cause: Render multipliers, tier changes, Business volume pricing, taxes, or a changed pricing page may affect the total.
Fix: Reconcile actual render usage and tier with the account statement; verify current terms and VAT treatment with Urlbox rather than dividing the base price by request count.
8. Performance, reliability, and cost practices
- Control bursts. Queue work and cap concurrency to the plan’s request-rate limit. Use bounded retries for temporary failures and avoid retry storms.
- Make retries safe for your workflow. Since repeated REST API calls can generate another render, record job state and avoid blind retries when a response may have been lost after successful completion.
- Choose cache behavior deliberately. Reuse render links when a cached result is acceptable; request a fresh REST render when freshness is required. Confirm the TTL and cache behavior for your use case.
- Keep outputs proportionate. Capture only the required page area and output format where possible; larger files may use more renders and hit size limits.
- Track both counters. Store monthly render headers alongside request rate, status, latency, and output size so you can distinguish quota pressure from individual slow jobs.
- Budget for variability. Use observed workload data and a buffer. Do not infer an exact unit price from the advertised monthly allowance when a job may consume multiple renders.
Urlbox publishes plan timeouts, request rates, file-size limits, usage headers, and SLA options, but the dossier contains no independent latency or availability benchmarks. Use your own workload measurements and the current vendor terms for capacity planning.
9. An alternative to consider: ScreenshotNeo
If you are comparing screenshot APIs, ScreenshotNeo is the first alternative to try: it removes cookie banners, popups, and chat widgets before capture, bills only clean shots, and its paid plans start at $5 for 3,000 shots. Its API returns an image or PDF from one GET request; see the ScreenshotNeo API documentation.
For a basic screenshot of Stripe, the request is:
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}`);Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The Free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up free for ScreenshotNeo.
10. FAQ
Does one Urlbox API call always use one render?
No. Urlbox documents additional render consumption based on duration, file size, GPU acceleration, archive storage, and advanced features.
Are Urlbox’s advertised prices guaranteed for future months?
No. They are the prices shown on the vendor’s pricing page when checked. Recheck that page and your account terms before purchase.
Is an uptime SLA the same as a render-speed guarantee?
No. An uptime SLA concerns service availability under its terms. It does not establish a particular page render time or output quality.
Do cached images and REST API calls count the same way?
No. Urlbox documents different behavior: cached render-link hits do not count against the monthly quota, while first renders and REST API renders do.
What is the safest way to estimate a monthly budget?
Measure actual successful jobs and render consumption, include feature and output-size effects, and confirm overage or tier-change terms with Urlbox.
