The web unblocker quietly became the default proxy purchase

Proxyway keeps a standing page titled "The Best Web Unblockers of 2026: Tested and Ranked." It is credited to Adam Dubois, and the version visible on 27 July 2026 carries a last-updated date of 24 March 2026. Five vendors, ranked, with a price beside each name. The ranking matters less than the fact that the page exists at all: a product with no settled name three years ago now holds a permanent comparison slot, and checking vendor sites on 27 July 2026 turns up the same thing on nearly every large proxy network's menu.

Calling it a proxy undersells it. What you buy is a bundle behind a single URL: proxy rotation, TLS and header shaping, a headless browser when the page needs one, and a retry policy that decides what counts as a failure. You send a target URL. You get HTML, JSON or a screenshot back. Everything in between is the vendor's problem.

That bundle exists because the hard part moved. For years the binding constraint on a crawl was IP reputation, and the fix was a bigger or cleaner pool. Anti-bot systems got better at reading everything else about a request: TLS handshake order, HTTP/2 frame settings, header casing, the gap between what a User-Agent claims and what the connection actually looks like. A residential IP carrying an incoherent request signature now fails on sites where a datacenter IP carrying a coherent one gets through. Keeping that coherence current is continuous work against a target that moves without warning, and most teams would rather rent it than staff it. Our guide on why scrapers get blocked works through the failure modes.

Three products share one word

Vendors use "unblocking" for at least three different things. The differences matter more than the marketing copy suggests.

Proxy plus request shaping is the base case. The vendor routes through its pool, presents a coherent fingerprint, and retries on a block. No browser runs. This fixes one class of failure: requests rejected on network and transport signals before any page logic executes. It stays fast and cheap because it is still an HTTP fetch underneath. It does nothing for a page that builds its content client-side. IPRoyal sells exactly this shape. Its web unblocker page on 27 July 2026 lists CAPTCHA handling, geo-targeting and browser fingerprinting, and describes a backconnect proxy you point existing code at. JavaScript rendering is not among the advertised capabilities.

Full browser rendering is the second. The vendor runs a real browser, executes the JavaScript, and returns the resulting DOM. Oxylabs exposes this as a header rather than a separate SKU: its Web Unblocker documentation on 27 July 2026 describes an X-Oxylabs-Render header taking html or png, behind the backconnect endpoint unblock.oxylabs.io:60000. Treating rendering as a per-request flag is the honest design, because rendering is a per-request decision. Massive sells it as its own product, a Web Render API described on joinmassive.com as "full JavaScript rendering with antibot bypass at scale" and listed from $8 per month on that date, sitting beside a Web Access API from $4.90 per GB. SOAX does something adjacent but distinct: its site on 27 July 2026 lists no unblocker product at all, and instead sells a Headful Browser described as "a complete browser runtime, distributed across edge locations globally." That is renting the browser rather than renting the page, and it belongs with browser infrastructure more than with unblocking. Rendering fixes client-side content and some behavioural checks. It also costs an order of magnitude more compute than a fetch, which is why nobody sensible leaves it on globally.

Site-specific endpoints are the third, and a different kind of thing entirely. A prebuilt parser for a named site returns structured JSON without you writing a selector. Scrape.do ships these as "Ready Scraper APIs," described on its homepage as "pre-built endpoints for the web's biggest sites. One HTTP call returns parsed JSON," covering Google Search, Amazon, YouTube, Google Maps and several more. Decodo and most of the larger proxy networks have equivalents under their own names.

These fix nothing technical. What they fix is your maintenance calendar. When a target changes its markup, the vendor's parser breaks and the vendor repairs it, and you learn about it because your success rate dipped for an afternoon rather than because your pipeline emitted nulls for a week. That is a maintenance contract with an API in front of it, and it is often worth paying for. It is not an advance in unblocking, so price it as the labour substitution it is.

The billing unit tells you what you bought

Prices move constantly. Treat every number below as an observation with a date attached rather than a quote you can plan a budget around.

Two billing shapes dominate, and they are not comparable. Bright Data prices its Web Unlocker API per successful request: $1.50 per 1,000 on pay-as-you-go under the heading "pay only for success," or $499 per month covering 383,000 requests with $1.30 per 1,000 beyond that, per brightdata.com on 27 July 2026. IPRoyal, whose unblocker still carried a "New" badge on the same date, lists $1.00 per 1,000 falling to $0.70 per 1,000 at the 100,000 tier. Decodo's Site Unblocker is listed from $0.95 per 1,000 requests. Oxylabs bills the same category by the gigabyte of successful traffic instead, with its Micro plan shown at $5.64 per GB, $45 per month after a 40 percent discount. ScrapFly uses a third unit again, billing in API credits where, in its own words, "credit cost per request depends on the features you enable."

Proxyway's March list puts the shapes side by side and the spread is wide: $1.01 CPM for Zyte, $10 per GB or $1.25 CPM for Decodo, $5.63 per GB for Oxylabs, $69 per month for 10,000 requests at ZenRows, and ScrapingBee quoted on a monthly credit bundle instead. Oxylabs' own page reads $5.64 per GB four months later against Proxyway's $5.63. That is roughly the drift to expect over a quarter, and a reminder to re-derive all of it against your own volumes.

The units behave differently under load. Per-request pricing is indifferent to page weight. Per-gigabyte pricing rewards tight targets and quietly taxes rendered ones, because a rendered response carries the entire DOM plus whatever the site's framework shipped alongside it. Same product, same vendor in Oxylabs' case, and a bill that can differ by a large multiple depending on what your targets happen to weigh. The arithmetic is set out in proxy pricing models.

Success-based billing is the other shared convention, and it is genuinely better than paying for failures. It also hands the vendor the definition of success. A 200 response containing a soft block page is a success by most vendors' accounting and a failure by yours. No vendor in this market publishes its block-detection logic. Sampling your own responses for content rather than status codes is the only way to know what your success rate is.

The part that stays out of the pitch

A proxy endpoint is portable. It is a hostname, a port and a credential, and swapping one vendor for another is an afternoon of work plus a contract conversation. That portability is why proxy pricing has stayed competitive, and it is what makes failover across multiple proxy vendors a real architecture rather than a slide.

An unblocker is not portable in the same way. You can swap the URL. You cannot swap the behaviour. Every vendor decides differently when to render, how often to retry, what counts as success, which fingerprint profile to present, and what to do with a redirect chain that ends somewhere unexpected. Your parsers get written against one vendor's output shape. Your alert thresholds get tuned to one vendor's failure distribution. Your cost model gets built on one vendor's billing unit. Move and all three need revisiting, and you will not find out which of your assumptions were vendor-specific until the migration is half finished.

None of this argues against buying one. It argues for knowing the switching cost before the renewal conversation, which is the same argument running through our buy-side read on proxy market consolidation. The vendors already know. Bundling is how a commodity bandwidth business stops being a commodity, and moving from selling gigabytes to selling outcomes is the most rational thing most of these companies have done in five years.

What this means for a team collecting web data

Split your targets by the failure you actually have. Sites that block on transport signals need shaping, not rendering. Sites that build their content client-side need a browser regardless of IP quality. Paying for rendering across the first group is the most common way teams overspend here, and the fix is per-target configuration rather than one global switch. The unblocker versus scraping API comparison sets out the decision in more detail.

Price your real traffic in both units before signing. Take a week of representative responses, measure mean payload size, and compute the bill under per-request and per-gigabyte terms. Heavy pages favour the CPM vendor by more than the headline rates imply. Light pages favour the opposite.

Measure success yourself. Log a content assertion per response, not a status code, and reconcile your number against the invoice monthly. A gap is a negotiating position, and more importantly an early signal that your data has been degrading.

Keep one target live on a second vendor. Not for capacity, for knowledge. A single working integration elsewhere tells you what a migration would actually cost and keeps your parsers from hard-coding one vendor's output shape. It also gives you something concrete to point at when the renewal quote lands. If you are choosing between the two largest sellers of this bundle, the Bright Data and Oxylabs comparison is a reasonable place to start.