Roxy Browser Alternatives for Cross-Border Sellers

Start with the compliance question, because it decides whether any of this tooling is appropriate for you. Running several accounts to disguise one business from a platform that permits one is a terms violation, and nothing below is advice to do that. What the rest of this post covers is the legitimate case: genuinely distinct businesses, brands or legal entities that a platform already allows you to operate separately, kept properly separated so that an operator mistake in one does not contaminate another.

That distinction is written into the platforms' own policy text, which is worth reading closely because it says something inconvenient for the entire antidetect category.

Amazon Global Selling's own knowledge article on operating multiple accounts states the rule as "only one seller account per region for selling merchandise, unless you have reasonable business need and all accounts are in good standing." The qualifying examples it gives are about business structure: distinct brands with separate operations, inventory for different independent companies, participation in an Amazon programme that requires separate accounts. On the question everyone actually wants answered, how Amazon decides two accounts are related, the same article declines to say. It notes that European and US sites may be associated and that Amazon will not share further detail on a sensitive topic, then advises reading the policies and warns that violations can mean product removal, held payments or loss of selling privileges.

TikTok Shop is the opposite: unusually explicit, and explicit in a direction that undercuts the sales pitch. Its Seller University entry answering how many seller accounts one can have sets the ceiling at five per verified entity, registered against the same business or personal identification, with each shop requiring its own unique email address and phone number. One official TikTok account links to one shop at a time. Group companies with separate legal entities apply for cross-entity binding through an account manager. Read that again: the gating identifiers are an entity document, an email address and a phone number. A browser fingerprint is not in the list, and the ceiling is a number TikTok hands you rather than one you evade.

Meta's Account Integrity policy is the most direct of the three. The restrictable conditions it publishes include an account "Owned by the same person or entity as an account that has been disabled" and one "Created or repurposed to evade a previous account or entity removal, including those assessed to have common ownership and content as previously removed accounts or entities." It also names "Creating or using an account or other entity through automated means, such as scripting (unless the scripting activity occurs through authorized routes and does not otherwise violate our policies)."

Common ownership. Same person or entity. Not same canvas hash. The written rule at all three platforms keys on who owns the business and whether the accounts are in good standing. None of it keys on the layer an antidetect browser edits. That does not make the browser useless, and I will get to what it genuinely buys you, but it does mean a vendor comparison organised around fingerprint benchmarks is answering a question the policy never asked.

Here is the model I use when a seller asks which tool to buy. A shop login is not one identity, it is five, stacked. Work out which layer is actually failing you before spending anything.

One row of five. Four of them are business-structure facts that no software edits, and the two rows marked "not published" are not published for a reason: platforms do not publish detection signals they would then have to defend. Anyone selling you a number for how well a browser defeats Amazon's association model is selling you a guess about an unpublished system.

The practical consequence is a sequencing rule. If your problem is layer one or two, that your entity documents or payout accounts overlap in a way the platform disallows, no browser fixes it and buying one wastes money while the underlying exposure grows. If your problem is layer five, dozens of shops sharing one Chrome profile, cookies bleeding between shops, an operator logging into the German shop from the session they last used for the Singapore shop, then a profile manager is the right purchase and the differences between vendors start to matter. If your problem is layer four, a single office IP fronting forty shops across six markets, the browser is the wrong aisle entirely and the longer treatment is in antidetect browsers versus proxies.

Most sellers who come to this decision have a layer-four and layer-five problem simultaneously, which is why the honest recommendation is almost never a browser on its own.

The best evidence for that framing is in RoxyBrowser's own documentation, and it is the single most useful thing I read while researching this post.

Roxy ships a separate ecommerce edition, documented under its own /docs/ecom/ tree, and that edition does not organise itself around profiles at all. It organises around accounts and devices. The device page defines the term without hedging: "A device is a network resource that provides an outbound IP to an account. It is not the computer running RoxyBrowser." Accounts and devices are stored separately, and the docs are blunt about the dependency. An unbound account "can be saved and edited, but Start remains unavailable." You cannot launch a shop until you have attached an IP to it. You either "purchase devices from Roxy or import your own IPv4 or IPv6 resources."

Then, on the accounts page, Roxy writes the compliance guidance itself: "Platform rules for multi-account operations vary. Follow the target platform's policies, use a stable outbound IP for important shops, and avoid sharing one browser environment across unrelated accounts."

That sentence is a vendor telling you, in its own docs, that the operative controls are the platform's policy and the stability of your outbound IP. The fingerprint comes third, phrased as hygiene rather than as evasion. I have read a lot of antidetect marketing and this is a notably straight statement. It also happens to be the correct one.

So what is RoxyBrowser, concretely, verified from its own pages today. The operator is LINKV TECH PTE. LTD., at 25 Seah Street #02-01, Singapore 188381, with NOVATECH HONGKONG GROUP CO., LIMITED also named in the footer. Support runs through support@RoxyBrowser.com, a Telegram channel and live chat. The desktop app covers Windows 10 or later in 64-bit and 32-bit builds, macOS 12 Monterey or later in Apple Silicon and Intel builds, and Linux on Ubuntu Desktop 22.04 or later. There is no Android or iOS app on the download page, which matters and I will come back to it.

Release cadence is real and checkable. The changelog's recent entries run chromium 154 on 2026/09/24, app 4.0.7 on 2026/09/23, app 4.0.6 on 2026/09/14, chromium 153 on 2026/09/09, app 4.0.5 on 2026/09/04 and chromium 152 on 2026/08/31. Three app releases and three kernel bumps inside a month is an actively maintained product, and the Chromium track is close enough to upstream that profiles will not stand out on version alone. Whatever else you conclude, this is not an abandoned tool.

Proxy support is broad: HTTP, HTTPS, SOCKS5 and SSH, with IPv4 and IPv6, and manual entry of host, port, username and password so you can bring your own. Two providers are integrated in the proxy panel, "Roxy IP (Official Self-Operated Service)" and "Rola-IP (Third-Party Provider)." The automation surface is a local HTTP API bound to 127.0.0.1 on a port returned when a profile opens, with a CDP WebSocket address alongside it, so Puppeteer and Playwright attach the usual way. Documented paths include /browser/list_v3, /browser/create, /browser/open, /browser/close, /browser/random_env, /proxy/list and /proxy/create.

Team permissions are four tiers: Owner, Manager, Editor, Viewer. An Editor "can edit profiles, accounts, and proxies within assigned projects" but cannot create or delete projects. A Viewer "can view and use profiles within assigned projects," which for a cross-border operation is the right default for a hired operator. Assigned permissions can only be lower than the inviter's. That is a competent model and better than several products charging more.

Roxy's pricing page computes most of its numbers from a profile-count slider, so only some figures are actually printed. Here is what the page showed me today, and nothing beyond it.

Three things follow from that table, and all three are arithmetic rather than opinion.

The discount is on a list price of $8.00. A 40% reduction that saves $3.20 and lands at $4.80 implies $8.00 for ten profiles, consistent with the $0.80 per-profile unit price in the same band. The numbers check out, which is more than I can say for some pricing pages.

Team collaboration is an add-on, not a tier feature. A workspace is $10 and each member is $5. Three operators therefore cost $10 plus $15, so $25 per month, before a single profile is paid for. Hold that figure, because it decides this comparison.

And the billing ladder starts at one day, which is unusual and genuinely useful for a seasonal push or a one-off account recovery, where you want capacity for a week and no commitment after it.

There is one lock-in detail worth knowing before you build a workflow on it. Roxy's own pricing FAQ describes what happens when you stop paying: "all your window data will be preserved, but the number of windows that can be launched will be limited to the initial 2 created." Your data stays, your ability to open it does not. If you have sixty shops in Roxy and your card fails, you have two launchable windows until you pay again. Plan an export path before you need one; the docs do list profile transfer and export features, so use them.

Because the fingerprint layer is one row of five, I selected the alternatives below on what a cross-border seller specifically needs from the other rows and from the operational reality of running shops across time zones. Four criteria, in the order they tend to bite.

First, mobile surface. TikTok Shop, Shopee and Instagram are phone-first products. Buyers browse them in an app, sellers increasingly administer them in an app, and some flows simply are not available on desktop web. A desktop browser emulating a phone user-agent is a weaker position than an actual Android environment, so I checked which vendors offer mobile fingerprints and which offer a real device.

Second, local-language operation. Roxy's primary market is Chinese-speaking, and its .cn site pitches itself at cross-border ecommerce and overseas social directly. A seller moving off it usually has operators who do not work in English. Site and support language is not a nice-to-have here, it is whether your warehouse staff can use the tool.

Third, seats bundled with capacity rather than billed separately. A cross-border operation is several people on one account set by definition: a listing operator, a customer-service person, an ads person, often in different countries.

Fourth, payment rails. If your business banks in Vietnam, Indonesia or Brazil, a vendor that takes only international cards is a procurement problem every month.

Two deliberate omissions. Multilogin, Kameleo and Dolphin Anty are capable products and three of them appear in almost every list like this one, but none was selected by the criteria above, so none gets a recommendation here. If your decision is really about enterprise diligence or raw concurrency rather than cross-border operations, those are the posts to read instead.

This is where the vendors genuinely separate, and where Roxy currently has a gap: its download page lists Windows, macOS and Linux, and no mobile app.

MoreLogin is the interesting answer because it does not emulate. Its Cloud Phone product is described on its own page as "a full Android environment running on cloud-based ARM infrastructure," and the page draws the distinction itself: "Android emulators simulate an Android operating environment on PC devices. In contrast, MoreLogin Cloud Phones run on ARM servers with a genuine Android system." Each phone is stated to have "a unique device fingerprint." Billing is "$0.006/min" or "from just $25/month."

Those two numbers give you a crossover you can compute. At $0.006 per minute, $25 buys about 4,167 minutes, roughly 69 hours a month, or about 2.3 hours a day. Below that, pay by the minute. Above it, take the monthly plan. A TikTok Shop operator logging in for twenty minutes twice a day pays around $7.20 a month per-minute, so the monthly plan is poor value. For anyone running a live-selling schedule, it inverts immediately.

MoreLogin's subscription side is modest and honest about it: the free plan carries 2 browser profiles, 2 team members, a Local API and browser automation with Selenium or Puppeteer. The Pro tier shows $5.4 per month, marked as 40% off $9, for 10 profiles. The footer lists "Android (Coming soon)" for its own app downloads, so the cloud phone is the mobile story, not a local app.

Octo Browser takes the emulation route and documents it plainly: "Octo Browser offers fingerprints that simulate Android devices. They are perfect for SMM, affiliate marketing, and other tasks that require working with mobile versions of websites." Android specifically, with no iOS claim on the page. The app runs on Windows, macOS Intel, macOS M series and Linux. The operator is BLACKBIRD SECURE BROWSING LTD, 41 Devonshire Street, Ground Floor, London W1G 7AJ.

Octo also has the cleanest printed price list in this group, which is worth something when you are budgeting across a year.

Note the structure: API arrives at Base, and team members arrive only at Team. Octo's own page advertises a 4.8/5 G2 rating and "uptime approaching 100%," both of which are the vendor's claims rather than anything I measured. Prices are in euros, so a seller banking in dollars carries the currency risk.

AdsPower covers the widest fingerprint surface of anyone here. Its own site states that "AdsPower supports fingerprints for Windows, macOS, iOS, Android, and Linux," which is the only iOS claim I found among these five, and it positions itself at exactly this audience: an "E-commerce & Dropshipping" section invites you to "Run multiple stores on Amazon, eBay, Shopify, Shopee, and Temu." The company is SUNFLOWER TECH PTE. LTD. The homepage claims "Trusted By 10M+ Users," which I am reporting as AdsPower's own unverified figure.

Its weakness for this comparison is price opacity. The pricing page shows plan structure with a double-dash placeholder where the numbers should be, so Professional, Business and Enterprise costs are not printed. What is printed is the automation ladder: Local API at 300 requests per minute on Professional, 900 on Business, 1,500 on Enterprise, plus an RPA robot and a synchroniser. Against Roxy's published API row topping out at 500 requests per minute, AdsPower's ceiling is three times higher. The free plan is 2 profiles and 0 team members. If you want this product, expect to talk to sales, and compare it against the ladder in our antidetect browser pricing breakdown before you do.

Language and payment are the criteria nobody benchmarks and every multi-country team trips over.

BitBrowser is the strongest answer, and the evidence is structural rather than marketing. Its sitemap index publishes 21 locale sitemaps: English, zh-Hant-TW, pt-PT, vi-VN, ru-RU, uk-UA, id-ID, fil-PH, th-TH, km-KH, pl-PL, de-DE, fr-FR, nl-NL, tr-TR, es-ES, ko-KR, ja-JP, ro-RO, it-IT and hi-IN. Thai, Vietnamese, Indonesian, Filipino and Khmer in one list is a company that has actually sold into Southeast Asia, which is the same map as Shopee and TikTok Shop's strongest markets. Its payment list reinforces it: Alipay, WeChat Pay, PayPal, Visa, Mastercard, Momo, YooMoney, VietQR, Pix and SBP.

BitBrowser's printed pricing is also the most seat-generous in this group. The free plan gives 10 profiles, 1 team member and a 50-per-day open limit. The paid examples listed on its own page are 50 profiles with 2 users at $10 per month, 100 profiles with 4 users at $15 per month, and 200 profiles with 8 users at $25 per month, with 10% off quarterly, 20% semi-annually and 30% annually.

Hidemium comes at the same regional market from a different direction and prices annually in dollars. Its own plan table reads: FREE at $0.00 with 5 profiles and no team members; BASIC at $153.00 per year with 30 profiles and 1 team member; ADVANCED at $204.00 per year with 100 profiles and 1 team member; PREMIUM at $714.00 per year with 1,000 profiles and 10 team members; BUSINESS at $4,284.00 per year with 13,000 profiles and 20 team members. Paid plans include browser automation with Puppeteer and API development. The free tier mentions "10.000 config browser fingerprint based on real-user data," with unlimited configurations on the top two tiers.

Hidemium prints a caveat I wish more vendors did: "prices are for reference only. Please install the app to view the most accurate prices." Treat its web numbers as indicative and confirm in-app before you commit a year of budget, because annual-only billing means a mistake costs twelve months.

Divide those annual figures and the shape becomes clear: BASIC is $12.75 a month, ADVANCED is $17.00, PREMIUM is $59.50, BUSINESS is $357.00. The trap is in the middle. ADVANCED gives you 100 profiles and exactly one seat, so a two-person team at 100 shops has to jump to PREMIUM and pay $59.50 a month for ten seats it does not need yet. Teams of two to four are the worst-served shape on that ladder.

Neither vendor specifies mobile fingerprint support in its own plan table, so if the phone surface is your constraint, these two are not the answer and the previous section is.

Now put the printed numbers together on one realistic shape: three operators, sixty shops. It is a common cross-border configuration, big enough to need separation and small enough that per-seat pricing hurts.

Roxy's sixty-profile subscription price is slider-computed and not printed, so I cannot state it, and I will not guess. What I can state is the part that is printed: the team charges. One workspace at $10 plus three members at $5 is $25 per month, on top of whatever the sixty profiles cost.

That $25 is the comparison.

BitBrowser's 200-profile, 8-user tier costs the same as Roxy's collaboration add-on alone, with the profiles included. For a price-led three-person team at sixty shops, that is close to decisive, and it is the reason my selection criteria put seats third rather than last.

The honest counter-arguments are worth stating. Roxy's permission model is more granular than a flat user count, with four roles and project-scoped visibility, and if you are handing profiles to contractors that granularity is worth real money. Octo's Team tier at EUR 169 brings 600 profiles and 6 members with API, which is a different scale of operation and priced sanely for it. Hidemium at PREMIUM is the only one on this list that gives you 1,000 profiles and 10 seats for a flat $714 a year, and if you are certain of your twelve-month shape, annual-only billing is a discount rather than a trap. MoreLogin is the only vendor here whose free plan includes both an API and a second team member, which makes it the cheapest way to test an automation idea before paying anyone.

The one thing I would not do is choose on profile count. Every vendor on this page will sell you more profiles than you can staff. Sixty shops needs three people and sixty stable IPs, in that order, and the profile ceiling is never the binding constraint. For the vendor-by-vendor view from the other direction, see our BitBrowser alternatives and AdsPower alternatives write-ups.

Return to the layer Roxy's own docs identify as the one that matters for important shops, and look at what the browser vendors actually hand you.

Roxy sells it, through the proxy store, bundled as "devices." The docs say pricing varies by duration of 30, 90, 180 or 360 days with "exclusive discounts of up to 15% off" for Roxy users, and that you can import your own IPv4 or IPv6 instead. Selling by duration rather than by traffic tells you the shape of the product: these are dedicated, static addresses held for a term, one per shop. For a shop login, that is the correct shape. A login session that changes country mid-session looks worse than one that never moves.

What duration-priced static IPs are poor at is the other half of a seller's work: price checking, keyword rank tracking, catalogue monitoring, competitor stock watching. That work needs breadth and rotation, and pinning it to the same dedicated address that holds your shop session is actively dangerous, because a scraping block against that IP now attaches to the address your storefront logs in from. Keep the two jobs on separate address pools. That separation is the single most useful operational habit in this whole category, and the background is in our guide to residential, datacenter and mobile proxies.

For the research half, SparkProxy starts from $75 per month, and the plans are packs rather than per-GB, with unlimited bandwidth included, so the billing unit is the plan and its concurrency rather than traffic consumed. That matters for catalogue work specifically, because catalogue pages are heavy and a per-GB meter turns an ordinary monitoring job into a variable cost you cannot forecast. The pool is 1M+ premium IPs across 80+ countries, with random rotation and 5-minute auto-rotation, over HTTP, HTTPS and SOCKS5, with IP whitelist or user:pass auth and 1 Gbps port speed. There is a 24-hour free trial with no credit card, and term discounts of 5% at three months, 10% at six and 15% at twelve.

For the mobile half, if your shops live on TikTok Shop or Instagram, a mobile exit is a closer match to how those platforms see their real traffic; the provider landscape for that is covered in best mobile proxy providers.

The expensive mistake in cross-border selling is binding a shop to an address that does not resolve where you think it does. You discover it weeks later, when a market's own storefront has been serving your operator the wrong currency the whole time and the account has quietly accumulated a geography mismatch.

Check it before you bind. SparkProxy's Scraping API is enough for this, and the one thing to get right is the envelope. Setting json_response=true is the only way to get job_id, status_code, duration_ms and credits_used back, and the body field inside it is base64. Decode before matching anything, or your marker checks silently fail against base64 noise. The format parameter is content conversion only and does not produce the envelope.

import base64
import requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "sk-your-key"

r = requests.get(API, headers={"X-API-Key": KEY}, params={
    "url": "https://httpbingo.org/ip",
    "render_js": "false",       # plain fetch, 1 credit instead of 5
    "json_response": "true",    # the ONLY way to get the envelope
}, timeout=120)

env = r.json()
print(env["status_code"], env["duration_ms"], env["credits_used"])

# env["body"] is base64. Decode it before you match anything.
html = base64.b64decode(env["body"]).decode("utf-8", "replace")
print(html[:200])

Now the actual pre-flight. For each shop, name the market, the exit country you intend to pin it to, and one string that only the correct market's page contains. A currency symbol is usually enough. Run it before you bind, and again after any proxy change.

import base64
import requests

API = "https://scrape.sparkproxy.io/api/v1"
KEY = "sk-your-key"

# One row per shop you actually operate: the market, the exit country you
# intend to pin that shop to, and a string the correct market's page must
# contain. Pick the marker by viewing the page once in the right country.
MARKETS = [
    {"shop": "sg-home-goods", "country": "sg", "marker": "S$"},
    {"shop": "de-home-goods", "country": "de", "marker": "EUR"},
    {"shop": "uk-home-goods", "country": "gb", "marker": "£"},
]

STOREFRONT = "https://httpbingo.org/html"  # swap for your own storefront URL


def preflight(row):
    r = requests.get(API, headers={"X-API-Key": KEY}, params={
        "url": STOREFRONT,
        "render_js": "false",
        "country_code": row["country"],   # +5 credits
        "proxy_type": "premium",
        "json_response": "true",
    }, timeout=180)
    env = r.json()
    if env.get("status_code") != 200:
        return row["shop"], "HTTP " + str(env.get("status_code")), env.get("credits_used")
    body = base64.b64decode(env["body"]).decode("utf-8", "replace")
    verdict = "ok" if row["marker"] in body else "WRONG MARKET"
    return row["shop"], verdict, env.get("credits_used")


for row in MARKETS:
    shop, verdict, credits = preflight(row)
    print("%-16s %-14s %s credits" % (shop, verdict, credits))

A daily liveness sweep over every listing URL you own is a different job, and it should not cost what the pre-flight costs. Batch mode requires render_js=false and the whole batch bills as 1 credit, which makes a once-a-day check over sixty URLs effectively free.

import requests

API = "https://scrape.sparkproxy.io/api/v1/batch"
KEY = "sk-your-key"

# Batch mode requires render_js=false, and the WHOLE batch costs 1 credit.
# Right for a daily liveness sweep over every listing URL you own.
urls = [
    "https://httpbingo.org/status/200",
    "https://httpbingo.org/status/404",
    "https://httpbingo.org/status/503",
]

r = requests.post(API, headers={"X-API-Key": KEY}, json={
    "urls": urls,
    "render_js": False,
}, timeout=300)

for item in r.json().get("results", []):
    print(item.get("url"), item.get("status_code"))

Budget it before you schedule it, because the difference between the cheap path and the careless one is two orders of magnitude. A plain fetch is 1 credit, render_js is 5 and defaults to on, country_code adds 5, and js_scenario adds 5 more and needs rendering enabled.

def credits(render_js=True, country_code=False, js_scenario=False):
    """Per-request credit cost, from the documented SparkProxy price list."""
    n = 5 if render_js else 1          # render_js defaults to TRUE
    if country_code:
        n += 5
    if js_scenario:                    # requires render_js=True, max 50 steps
        n += 5
    return n


shops = 60          # profiles you actually launch
checks_per_day = 1

plain = credits(render_js=False)
pinned = credits(render_js=False, country_code=True)
rendered = credits(render_js=True, country_code=True)

for label, unit in (("plain fetch", plain),
                    ("pinned country", pinned),
                    ("rendered + pinned", rendered)):
    per_day = shops * checks_per_day * unit
    print("%-20s %2d credits each  %5d/day  %6d/30d" % (
        label, unit, per_day, per_day * 30))

print("batch sweep (render_js=false):      1 credit for all %d urls" % shops)

Running that on 2026-10-09 prints the ladder below, and it is the argument for not rendering by default:

plain fetch           1 credits each     60/day    1800/30d
pinned country        6 credits each    360/day   10800/30d
rendered + pinned    10 credits each    600/day   18000/30d
batch sweep (render_js=false):      1 credit for all 60 urls

Sixty shops checked once a day with a pinned country and full rendering burns 18,000 credits a month. The same sweep as a plain batch costs 30. Reserve the expensive path for the pre-flight you run when a shop is created or its proxy changes, and let the daily sweep be a batch. The free tier is 1,000 credits, which is enough to pre-flight about 166 shops once at the pinned-plain rate before you pay anything.

Everything above came from the vendors' own pages or docs, read on 2026-10-09. Here is what did not, stated plainly rather than quietly smoothed over.

Roxy's Pro, Business and Enterprise monthly prices are not printed anywhere I could reach. The pricing page computes them from a profile slider, and the only unit price shown is $0.80 per profile in the 0-to-10 band. The same is true of AdsPower, whose pricing table renders a dash placeholder in place of every figure. I have not guessed either, and you should distrust any article that quotes a confident monthly price for those tiers without saying where it came from. Third-party sources I checked while researching this disagreed with each other and with the vendor pages, which is exactly why they are not cited here.

The TikTok Shop figure of five seller accounts per verified entity comes from TikTok's own Seller University knowledge base. I could not render that page myself: it returns HTTP 504 to a plain automated client, measured at 6.8 seconds today, while every vendor site in this comparison answered 200 to the same client in under a second. Treat the number as TikTok's own published answer, and re-check it in a real browser before you plan around it, because platform ceilings change.

Shopee is named in this post as a market, not a cited policy. Its seller help is market-specific and blocks automated clients, so I have asserted nothing about its account rules.

Several figures are vendor claims that I am passing through as claims, not facts: AdsPower's "Trusted By 10M+ Users," Octo's 4.8/5 G2 rating and "uptime approaching 100%," Roxy's statement that it bypasses the Fingerprint and CreepJS detection tools, and the "20,000+ high-authority real overseas accounts" advertised alongside Roxy's separate done-for-you Global Marketing service, which is priced per video from $5.00 at ten videos down to $3.00 at five hundred. None of those is measured by me, and no success-rate or detection figure in this post is presented as established.

Mobile fingerprint support for Hidemium and BitBrowser is listed as "not specified" above because their own plan tables do not specify it, not because I established its absence. Likewise, I read Octo's and MoreLogin's pricing in English and did not survey their full locale coverage the way BitBrowser's sitemap let me, so those cells say "not checked" rather than "none."

Finally, the fingerprint layer itself. I did not benchmark any of these browsers against any platform's detection, and I would distrust anyone who published such a number, because the platforms do not document what they check. The measurable claims in this post are the DNS and HTTP checks I ran, the prices on the pages, the release dates in the changelog, and the credit arithmetic the script prints. For how fingerprint surfaces are constructed and what they do and do not cover, see our antidetect browser fingerprint protection explainer.