# Migrate anti-detect browser profiles by shape

> To migrate anti-detect browser profiles, Mosaic reads which product wrote the file from its fields, keeps what that product recorded and draws the rest.

Source: https://mosaicbrowser.com/blog/importing-by-shape

## Importing other browsers' libraries by shape, not file name

To migrate anti-detect browser profiles, Mosaic reads which product wrote the file from its fields, keeps what that product recorded and draws the rest.

![5: Five products, told apart by their fields, beside a screenshot: filtering Mosaic profiles by tag: only the profiles tagged "shop" are listed](https://mosaicbrowser.com/covers/importing-by-shape.webp)

To migrate anti-detect browser profiles into Mosaic, you drop the other product's export on the import dialog and it works out which product wrote it from the fields inside, never from the file name. It keeps the name, notes, proxy and whatever hardware and locale values that product recorded. Everything else is drawn fresh, and the dialog lists what it left behind before anything is imported.

The importer is `src/main/store/foreign-import.ts`, and it reads exports from GoLogin, Dolphin Anty, AdsPower, Octo Browser and Multilogin. We wrote it because somebody with two hundred profiles somewhere else is not going to rebuild them by hand. If we answered their export with "this archive was not made by Mosaic", we would really be telling them not to switch.

The file has three rules in it, and the comment at the top spells them out.

## Rule one: a file name proves nothing

You can call a zip `gologin-export.zip` and put an AdsPower record in it. And if GoLogin renamed its export next month, anything keyed on the name would stop working the same day. So we look for fields instead. Each product has a signature, a set of keys that only that product writes:

| Product | What the signature looks for |
| --- | --- |
| AdsPower | snake_case `user_proxy_config` or `fingerprint_config` |
| Dolphin Anty | a `useragent` wrapped as `{ mode, value }`, beside `webglInfo` |
| GoLogin | `navigator.resolution` |
| Octo Browser | a `title` (not `name`) with a nested `fingerprint` |
| Multilogin | `browserType`, with `navigator` or `network` |

No record can match two rows of that table; we picked the keys so it couldn't. Getting the vendor wrong is worse than not knowing it. Call a Dolphin file "GoLogin" and the import still says it worked, then goes looking for the proxy under `proxy.mode`, where Dolphin never put it.

There's a check for this in the build, `npm run check:import`. For each product it makes a sample file in the documented shape and asks three questions. Is it recognised? Is it recognised as itself, and not as a neighbour? Do the locale and the proxy actually arrive, from bare JSON and from a zip? We wrote it because the failure makes no noise. A vendor renames one field, the signature stops matching, the file drops to the generic reader, most of each profile is lost, and the dialog reports success anyway.

Mosaic is a desktop app

Email yourself the link and open it on your computer.

[How it works: Machines that exist](https://mosaicbrowser.com/features/real-fingerprints)

## Rule two: never invent a value

None of these products writes down a whole machine. GoLogin has a screen size and a User-Agent. Octo has CPU and RAM, spelled its own way. Not one of the five readers gets a GPU out of the file. You could plug each hole with something common, say a 1920×1080 screen and whatever GPU is most popular this year.

We do the opposite. What the vendor recorded is passed to the generator as a constraint, and the generator draws everything else to agree with it from [real hardware records](https://mosaicbrowser.com/features/real-fingerprints). Filling gaps with constants is how two hundred imported profiles end up sharing one screen size and one GPU. That is worse than two hundred freshly drawn profiles, because a value shared across a library is a join key. The values a page compares are listed in [browser fingerprint](https://mosaicbrowser.com/glossary/browser-fingerprint).

For the same reason, a vendor's canvas and audio seeds are dropped. They were tuned for that vendor's engine and mean nothing in ours.

## Rule three: say what was dropped

The dialog reads every file as it lands and prints its verdict before anything is created: "Detected as Dolphin Anty" with the count, and a note that every profile "will be tagged Dolphin Anty so you can tell later where it came from". Under it is a line starting "Not carried across" that names the fields staying behind, such as Dolphin statuses or AdsPower group membership.

![Mosaic profiles filtered by one tag, with the tag filter open beside the Tags column](https://mosaicbrowser.com/shots/tags-filter.png)
*The vendor's name arrives as a tag you can filter by*

The tag is there for later. Six months on, the only way to know why a profile has an odd screen size is to know where it came from. The tag is added inside the importer rather than by whoever called it, so provenance survives whether the import started in the window, the REST API or the MCP server.

## The file we should have been surest about

One bug report against this code was about our own export. On 18 September 2026, dropping a `mosaic-profiles.zip` back into the import dialog reported "Unrecognised format · 1 profile". The zip held two profiles, and the dialog warned that the fingerprint would be lost on a round trip that in fact kept everything.

The import itself was fine. It had always read a Mosaic archive by its `mosaic-profile.json` entries. The detector was at fault. It only asked "which competitor is this?", so our own file fell through to the generic branch, which counts a profile only when some JSON document has a top-level `name`. Detection now counts `mosaic-profile.json` entries first and answers "Mosaic · 2 profiles · certain". It counts entry names rather than parsing, because entry names are what the import keys on, and a second description of the archive's shape is the copy that drifts.

## Migrating anti-detect browser profiles from a product not on the list

Identory is missing on purpose. Its export format is not documented well enough for a signature that would not misfire, and a wrong signature is worse than none: it would claim a vendor and then map fields wrongly. Its files go to the generic reader, which takes the name, notes, proxy and any locale fields it finds. The dialog offers that reader explicitly, with the words "Not recognised as any known product", and never picks it in silence.

Moving profiles keeps what identifies each account. It does not change what a platform allows, so the accounts you bring across should be ones you are entitled to run. Which signals still have to stay apart after a move (cookies, exits and timing) is covered in [how to manage multiple accounts without getting linked](https://mosaicbrowser.com/guides/how-to-manage-multiple-accounts-without-getting-linked).

## Questions

### Which products can Mosaic import profiles from?

GoLogin, Dolphin Anty, AdsPower, Octo Browser and Multilogin, plus Mosaic's own export zip. A JSON file from anything else is offered on the fields every product shares, and the import dialog says it did not recognise the vendor.

### Does renaming the export file change how it is imported?

No. Mosaic ignores the file name and looks at the fields inside. A file called gologin-export.zip that holds an AdsPower record is imported as AdsPower.

### Are the other product's canvas and audio settings carried across?

No. A noise seed tuned for another product's engine says nothing true about ours, so the import dialog lists those settings under Not carried across. Name, notes, proxy, start pages and the hardware and locale values the product recorded are kept.

### Why is Identory not on the list?

Its export format is not documented well enough for us to write a signature that would not misfire. A signature that claims the wrong vendor maps fields wrongly, which is worse than offering the file to the generic reader and saying so.

## Related

[Machines that exist: fingerprints drawn from real hardware](https://mosaicbrowser.com/features/real-fingerprints): Mosaic draws each profile's GPU, screen, CPU, memory and fonts from one real device, so the parts of a fingerprint agree with each other and with the host.

[How to manage multiple accounts without getting them linked](https://mosaicbrowser.com/guides/how-to-manage-multiple-accounts-without-getting-linked): Accounts get linked by shared cookies, IPs, fingerprints and habits. Give each its own profile, exit and history, then test it before you trust it.

[Browser fingerprint: what a site can read about your machine](https://mosaicbrowser.com/glossary/browser-fingerprint): A browser fingerprint is the set of values a site reads about your browser and computer, which together recognize you without cookies. What goes into one.

[Why OS spoofing fails on fonts: a Mac makes Mac profiles](https://mosaicbrowser.com/blog/a-mac-makes-mac-profiles): Why OS spoofing fails on fonts: they come from the computer, not the claim. A Linux profile made on our Mac showed 1 font where macOS showed 159.

[How do websites detect multiple accounts?](https://mosaicbrowser.com/guides/how-do-websites-detect-multiple-accounts): Websites detect multiple accounts by what two accounts share: cookies, the IP address, the browser fingerprint, payment and phone details, and habits.







## Mosaic, on your own computer

The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number.

Mosaic is a desktop app

Email yourself the link and open it on your computer.