Multilogin Detection

How to detect Multilogin in 2026

Multilogin sells browser profiles that each carry their own fingerprint, cookies and proxy, and since July 2026 it leads with Android cloud phones for running social media accounts. Its browser engine is Mimic, built on Chrome; the Firefox-based Stealthfox is legacy. Maskbreak does not look for Multilogin by name. It checks whether the browser can back up what it claims to be, whether the visit comes through a proxy and whether a script is driving it, and it blocks a fake browser by default.

Last reviewed: September 2026. Facts about Multilogin come from its own site, help centre and press releases, read on 24 and 25 September 2026.

What Multilogin is in 2026

Multilogin says it was founded in 2015 and is headquartered in Abu Dhabi. It is sold openly for running many accounts, and on 31 July 2026 it repositioned as "a cloud phone platform for managing multiple social media accounts" (release). Its homepage now leads with Android cloud phones, with the multi-account browser beside them.

The browser runs on Mimic, Multilogin's Chrome-based engine. Stealthfox, the Firefox-based one, is legacy and stays on its final core, version 146, and Multilogin recommends Mimic for new profiles (help page, updated 18 September 2026). Every plan includes built-in residential and mobile proxies, and ISP proxies start at the Pro 50 plan. Selenium, Puppeteer and Playwright support, an API and a CLI come with the Pro and Business plans. The free plan gives 5 profiles, browser and cloud phone combined; paid plans start at $7.08 a month billed annually, or $11 billed monthly (pricing, read 25 September 2026). On 26 August 2026 Multilogin released an open-source agent that lets AI agents such as Claude Code and Cursor run social accounts on its cloud phones (release).

Many buyers use it for legitimate agency and social media work. Fraud teams meet the same kind of software at signup, at bonus claims and in account takeover. The browser looks the same either way; what the account does next is what differs.

How Maskbreak checks a Multilogin session

Maskbreak has no Multilogin signature and never names the product. The browser snippet on your form collects two tokens, your server sends them to POST /v1/evaluate, and the answer is one decision (allow, review or block) with the reasons behind it. These are the parts that apply to a Multilogin profile.

The fake-browser flag

device.antidetect is true when Maskbreak's device check sees a fake or tampered browser. It adds the reason antidetect_browser and returns block by default, the same as a proxy, Tor, automation or an emulator. It flags the class of tool, not the product, and there is no published detection rate for Multilogin or any other browser.

What the check looks for

Claims that something measurable can contradict. On our own bench (a JavaScript spoofing shim, not Multilogin), a user agent that disagreed with the engine underneath and a WebGL renderer naming a graphics chip the machine did not have each tripped the flag; canvas or audio noise on its own did not. A Mimic profile that claims Chrome really runs on a Chrome engine, so the useful contradictions are the ones a profile adds on top: another browser, another operating system, other hardware.

Tampering score (0–1)

device.tampering_score comes from the device check and is not a probability of fraud. On our bench it stayed near zero while the flag moved. Route on decision and reasons, not on a threshold of the score.

Scripted profiles

Multilogin sells Selenium, Puppeteer and Playwright control on its paid plans. When the device check sees signs that a script is driving the browser, it adds automation_detected and blocks by default. It does not name the framework; bot detection covers this signal in full.

The bundled proxies

Home and mobile exits are the hard case for IP lists, and every Multilogin plan includes them. On a live visit, an exit that Maskbreak's network intelligence recognises as a proxy adds proxy_detected and blocks; a VPN on its own adds vpn_detected and goes to review, not block. network.service names the operator when known. See proxy detection.

Cloud phones

We have not tested Multilogin's cloud phones. They are Android devices rather than a browser build, so the fake-browser flag is not the check to count on there. When a phone's browser opens your form, the same evaluation runs: the proxy check still applies, and if the device check sees an emulator it adds emulator_detected and blocks by default. device.virtual_machine is reported too; a virtual machine on its own lists virtual_machine and asks for review, never a block.

One device, many of your accounts

Send your own accountId and device.linked_accounts counts how many of your accounts this device has been used with; more than one adds multi_account_device, which is reported but does not change the decision unless you set a rule for it. Links stay inside your account, stored as one-way hashes. device.times_seen is different: it counts sightings across all Maskbreak customers. A profile switcher can produce a new visitor ID per profile, so treat linking as an extra layer, not the main one.

A script-driven Mimic profile on a bundled residential proxy, with both the device check and the network intelligence seeing it, would come back like this example response (trimmed):

// example response, POST /v1/evaluate
{
  "decision": "block",
  "risk_score": 100,
  "reasons": ["proxy_detected", "antidetect_browser", "automation_detected"],
  "network": {
    "vpn": false,
    "proxy": true,
    "datacenter": false,
    "tor": false,
    "residential": false,
    "service": null
  },
  "device": {
    "antidetect": true,
    "automation": true,
    "virtual_machine": false
  }
}

Each of the three reasons would block on its own. The score adds up past 100 and is capped there, so route on decision, not the number. residential is false because the proxy flag fired: the field means "no proxy or cloud-server flag", not "home connection".

The honest version: a well-built profile can pass the device check, and Maskbreak has no published detection rate for Multilogin or anything else. Chrome now ships every two weeks, Chrome-based engines such as Mimic follow it, and each new build can remove a contradiction that got noticed. What the layers buy you is independence: a profile that passes the device check can still arrive through a proxy that blocks, under a script that blocks, or on a device already linked to another of your accounts.

Putting it to work

Add the browser snippet to signup, login, checkout or a bonus claim, and have your server forward its two tokens to /v1/evaluate. Start in watch mode: log the decision and let every visitor through, then switch to enforce once the Events log looks right. The quickstart has the handler, and the API reference documents every field.

If Multilogin users are your customers. Agencies and social media managers run it for legitimate work, so you may want "Fake browser (antidetect)" set to review on the console's Rules tab. A rule changes the answer only for the signal it names: the same visit still blocks if it also comes through a proxy or is driven by a script, unless you set rules for those signals too. When a rule changes the answer, engine_decision keeps the default. Block or review antidetect browsers? weighs the choice.

The antidetect hub lists the other browsers and who makes them, the lab notes show the bench tests, and a longer essay on Multilogin detection covers signup, login and checkout.

Put Multilogin traffic under a layered lens.
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month.

Start free — no card Try the live scanner