Frequently asked questions

A browser that gives each profile its own consistent device fingerprint, cookies, storage and proxy — so websites see independent, genuine-looking devices instead of one machine running many accounts.

Dual Login ships real, hardware-consistent fingerprints (canvas, WebGL, fonts, audio, timezone) rather than blank or spoofed values that stand out. The biggest tell is usually the proxy IP, not the browser — use clean residential/mobile IPs for sensitive accounts.

Incognito only clears local data; a VPN only changes your IP. Neither changes your fingerprint, and both leak the same device signature across accounts. Dual Login isolates the fingerprint, storage and proxy per profile.

For most multi-account work, yes. You can bind HTTP, HTTPS, or SOCKS5 proxies per profile and Dual Login auto-matches timezone and locale to the proxy's exit.

Yes — admins and managers can share specific profiles with members, so people launch accounts without ever seeing the passwords.

Yes. Attach Selenium, Puppeteer or Playwright over CDP, or drive any running profile with plain HTTP (goto, click, type, eval, screenshot). See the Docs.

Desktop apps for Windows, macOS (Apple Silicon & Intel) and Linux, plus a web console to manage profiles, team and billing.

By card via Stripe or with crypto via NowPayments, right inside the app. Plans are monthly; you can start free with 10 profiles.

Yes — the software itself is legal, and it is used every day for legitimate work like QA testing, ad-account management, market research and privacy. What matters is how you use it. Dual Login's terms prohibit fraud, phishing, spam and any illegal activity.

Fingerprinting is how sites identify a device without cookies, by reading properties like canvas and WebGL rendering, fonts, audio, screen size and timezone. Combined, they form a near-unique ID. Dual Login gives each profile its own consistent fingerprint so profiles look like separate devices.

Yes. Each profile gets a stable, per-profile canvas hash and a matching WebGL renderer, applied at the engine level. They stay consistent across sessions — which is what real devices do — rather than randomising on every load, which is itself a red flag.

It removes the technical link between your accounts, so one ban doesn't cascade to the others. It cannot override a platform's rules — how you operate each account still matters. No tool can honestly guarantee you'll never be banned.

As many as your plan allows and your computer can handle. Each profile is its own isolated browser; the practical limit is your RAM. Low-RAM mode lets you run more on modest machines.

Yes. You can paste or bulk-import cookies and localStorage into a profile, and logins are captured and re-injected so sessions survive across launches and machines.

Clean residential or mobile proxies, one per profile, matched to the account's country. Datacenter proxies are cheaper but widely flagged. Dual Login supports HTTP, HTTPS and SOCKS5 and masks WebRTC to the proxy's exit IP.

Yes. When a profile is proxied, Dual Login masks WebRTC to report the proxy's exit IP, so your real IP never leaks around the proxy.

Yes — media buyers use it to keep multiple ad accounts and Business Managers isolated. Match a clean proxy per profile, keep the location story consistent, and warm accounts up gradually. You remain responsible for following each platform's policies.

Yes. Each store or buyer account gets its own fingerprint, proxy and sealed storage, so they aren't linked by device or IP. Keep proxies stable per store and operate within the marketplace's rules.

Yes. The free plan includes real fingerprints, per-profile proxies and the automation API, with a capped number of profiles and one seat — enough to test the workflow on your own accounts before you pay.

Plans start free, with paid tiers for growing operators and agencies that raise profile counts, add team seats and unlock more automation. See the pricing page for current details.

Cancel any time from your account. Your plan stays active until the end of the current billing period, then moves to the free plan. See our Refund Policy for details.

You can request a refund of your most recent payment within 14 days if your usage is consistent with a good-faith evaluation. Contact billing@duallogin.com. Full terms are in our Refund Policy.

Data is encrypted in transit and, for sensitive fields and synced profiles, at rest. Passwords are stored as salted hashes. With the desktop app, your profile data stays on your own machine. See our Security Policy.

With the desktop app, profiles live locally on your computer. If you enable cloud sync, encrypted copies are stored so you can access them from other devices.

Yes. Attach Puppeteer, Playwright or Selenium to a real, fingerprinted profile over CDP, or drive any running profile with a plain HTTP API — goto, click, type, eval, screenshot. Sample projects are in the docs for Python, Node, C#, Java, Go and PHP.

The core job is the same, but tools differ on fingerprint realism, proxy automation, scripting depth, team features and price. Dual Login focuses on native (engine-level) fingerprints, per-profile proxies with geo-matching, both CDP and HTTP automation, and a genuine free plan — try them side by side.

Yes. You can recreate profiles and import cookies and proxies. Start on the free plan, migrate a few profiles, and confirm they pass a fingerprint checker before moving your whole operation.

Yes — desktop apps for Windows, macOS (Apple Silicon and Intel) and Linux, plus a web console for managing profiles, team and billing.

Yes. Profiles can present as Windows, macOS, Android, iPhone or iPad, with the matching user agent, screen, GPU and touch characteristics.

Your account moves to the free plan. Profiles beyond the free limit are retained but not launchable until you free up slots or upgrade again; nothing is deleted just because you downgraded.

Yes. Invite members under managers, share only the profiles each person needs (by access, not passwords), and keep an audit trail of activity.

Report suspected misuse to abuse@duallogin.com, and security vulnerabilities to security@duallogin.com. We review every report.

We are GDPR- and CCPA/CPRA-aware: we honour data-subject rights, use Standard Contractual Clauses for international transfers, and offer a Data Processing Addendum to business customers. See our Privacy Policy and Trust Center.

No, and it is worth being precise about the difference. It makes your accounts hard to link to each other, which is a separation problem. Anonymity is a different problem -- hiding who you are from a determined observer -- and it involves your network, your payment methods, your writing style and your behaviour far more than your browser. Dual Login is built for the first problem. If the second is what you need, the tools for it are different ones.

Because the IP address is a fingerprint too, and a shared one is conclusive. Two accounts arriving from the same address at the same times, doing similar things, are linked regardless of how convincing each browser identity is -- the platform does not need the fingerprints to match when the network already answered the question. The reverse is also true: a perfect proxy behind a browser reporting an identical machine to fifty others fails the same way. Both layers or neither.

It depends on what you are doing, and the honest answer is that it is a spectrum rather than a rule. Residential and mobile addresses look like consumer connections and carry the best reputation, at the highest price. Datacentre addresses are cheap and fast and are recognised as datacentre addresses by anything that checks, which is fine for research and poor for consumer platforms. The important part is not the category but the sharing: an address only you are using beats a technically superior one being used by two hundred other people.

We cannot promise otherwise, and anyone in this market who does is describing a system they do not have access to. Platform decisions weigh IP reputation, account age, payment instruments, phone numbers, content and behaviour alongside device identity. Dual Login handles the device layer properly, which removes one whole category of linkage. It cannot make an account compliant with a policy it is breaking, and it cannot compensate for twenty signups in an hour from one machine.

Yes, and it is one of the reasons the product exists. Cookies and local storage are captured from the running browser and travel with the profile, so opening it on a second machine arrives at a signed-in session rather than a login screen. Two safety rules make that trustworthy: a profile checks for a newer copy before opening, so you never work on a session another machine has already replaced, and an empty session is never written over a good one.

Yes -- the browsers are real processes on your machine, so the machine has to be running them. What you do not need is a browser-automation framework or a driver install: profiles can be driven over CDP or plain HTTP, which is deliberate, because most automation in this field is a script or job runner that can make a request rather than something written against WebDriver.

It achieves a similar separation at a fraction of the cost. A VM per account is genuinely isolated and genuinely expensive -- gigabytes of memory and a full operating system for each identity, which puts a hard ceiling around a handful on ordinary hardware. Profiles cost a browser process each, so the same machine holds dozens. VMs also share a weakness people forget: they typically leave through the same network connection, so without separate proxies the accounts are linked anyway.

It does one small part and advertises it confusingly. A private window discards cookies and history when you close it, which is useful against someone using your computer afterwards. It changes nothing about your fingerprint -- same GPU, same fonts, same canvas hash, same screen, same IP -- so two accounts used in two private windows are as linkable as two accounts used in one normal one.

As many as your memory allows, which is almost always fewer than your plan allows. Each profile is a real browser process, so roughly five concurrent profiles per 4 GB is realistic with low-memory mode on: dozens at once on a 32 GB machine, hundreds in sequence. Plan limits describe how many identities you may store, not how many browsers your hardware will hold at one moment.

Nothing dramatic, and nothing hidden. Profile directories are on your own disk and stay there; anything you synced remains in the account. The licence to run the software is tied to an active plan, so that ends -- which is why the useful habit is exporting anything you would miss before a lapse rather than after.

You can, and it is usually a mistake. The whole value of a profile is that it is one device with one story; putting two accounts inside it means the site sees them share cookies, storage and every fingerprint value, which is precisely the linkage the tool exists to prevent. The only case where sharing is sensible is two accounts you would be happy to have associated anyway.

Naming discipline before you need it, then groups, then notes. The thing that actually breaks at scale is not the software -- it is the operator’s ability to say which profile holds which account six months later, after they were created in a hurry and named after whatever was on screen. Put the platform and the account identifier in the name from day one, use groups for the dimension the name cannot carry, and keep the proxy assignment visible.

A window is a view; a profile is an identity. Opening a new window of the same profile shows you the same cookies, the same storage and the same fingerprint, because it is the same browser process. Opening a second profile starts a separate process with its own data directory and its own reported device -- which is why one costs you memory and the other does not.

It depends entirely on how the automation is delivered. The conventional route announces itself: WebDriver sets a flag any page script can read, and holding a debugger connection open is itself a signal. Driving a profile here issues clicks and keystrokes as trusted input events at the protocol level, with no automation flags on the launch, so the browser looks the same whether a person or a script is using it. What automation cannot disguise is inhuman pacing -- perfectly regular intervals are a behavioural signal no input layer fixes.

Yes. The free plan is ten profiles with no card and no countdown, and it runs the same engine as every paid plan rather than a limited build. It exists specifically so that you can run the only test that matters -- whether your sessions hold over a week -- before any money changes hands.

It is a browser, so it works wherever a browser works -- there is no per-platform integration to wait for and no compatibility list to check. What differs by platform is not whether the tool functions but how much scrutiny the platform applies, which is a property of their risk models rather than of the software. The community threads are the best current source on what specific platforms are doing this month.

Yes -- the free plan is the same product with a smaller ceiling, so upgrading changes the number, not the data. Profiles, cookies, groups and settings carry straight over, which is the point: the evaluation you did on free was an evaluation of the thing you end up paying for.

Three doors, by question type. The help centre covers setup and billing with screenshots. The community covers how-do-others-do-this, with answers from operators who are not paid to be positive. Support covers anything specific to your account. Between the three, the question that goes genuinely unanswered is rare -- and if you find one, the community thread pointing that out is itself useful.

No -- that would defeat the product. Each profile is its own browser process with its own data directory: cookies, storage, cache and history are fully separate, and nothing one profile writes is visible to another. The only data that leaves your machine is what you explicitly sync to your account, per profile, for the portability of your own logins.

Under an hour for a working first profile -- install, add a proxy, create, check, sign in. Under a day for a small working set, mostly spent on proxy choices. About a week before you should trust the setup with accounts you cannot afford to lose, because that week of session survival is the real acceptance test and nothing substitutes for it.

Yes -- the same support as always, plus a help centre written specifically for the first week and a community where the how-should-I-structure-this questions get answered by operators who faced the same blank slate. Most people need exactly one nudge, and it is almost always about proxy choice rather than the software.