Chrome multiple profiles generator: what it really does

Clicking through the profile creation dialog is fine once. Doing it twenty times, naming each one, dismissing each welcome screen and setting each avatar, is the kind of task that sends people looking for a generator. The tools that turn up in that search range from three line shell scripts to commercial products with monthly fees, and they all describe themselves in the same way.

Underneath, almost all of them are doing one thing: passing a command line flag to Chrome in a loop. Understanding which flag, and what Chrome writes when it receives it, decides whether a bulk creation script is a five minute job or a maintenance problem that outlives the reason it was written.

What a generator actually generates

Chrome creates a profile the first time it is asked to open one that does not exist. Launching the browser with a --profile-directory value pointing at a folder name that has never been used produces that folder, populated with a fresh set of databases, and adds an entry for it in the browser's own list of profiles. No dialog, no welcome screen, no manual naming.

That behaviour is the entire mechanism. A generator loops over a list of names, launches Chrome once per name, waits for the folder to appear and quits. Everything else the paid tools add sits on top of that: proxy assignment per profile, user agent overrides, cookie import, scheduling. The creation step itself is not proprietary and is not complicated.

It is worth knowing what appears after that single launch. The new folder contains its own Cookies, History, Login Data, Bookmarks, Preferences and Extensions, which is to say a complete and independent browsing identity. At the root of the user data directory, the Local State file gains an entry under profile.info_cache keyed by the folder name, carrying the display name, the avatar, the colour and a last active timestamp. A profile that exists on disk but has no entry there will not appear in the profile picker, and an entry with no folder produces an error at launch.

The two flags do different things and are easy to confuse

Almost every problem with generated profiles traces back to picking the wrong one of these two.

Flag	What it separates	What stays shared
--profile-directory="Profile 7"	Cookies, history, passwords, bookmarks, extensions, sessions	One Chrome process tree, Local State, the profile picker, browser updates, the crash handler
--user-data-dir=/path/to/dir	Everything above, plus the profile list, the singleton lock and the entire browser instance	Nothing except the installed application binary

A profile directory is the normal, supported unit. Profiles created this way appear in the profile picker, switch with the avatar menu, share one running browser and behave exactly like profiles made through the dialog.

A separate user data directory is a different animal. Chrome treats it as an unrelated installation, so it gets its own dock icon behaviour, its own singleton lock file and its own update state. Automation frameworks default to this because test runs must not touch a person's real browser. Generators that want profiles a human will actually use should not, because twenty user data directories means twenty independent copies of the browser's shared state and no profile picker tying them together.

The rule of thumb is simple. If a person is going to switch between these profiles by hand, use profile directories. If a script is going to drive them and nobody will look at them, separate user data directories are cleaner.

Naming is where generated profiles go wrong

Chrome distinguishes two names for every profile and generators routinely conflate them. The folder name is fixed at creation, is what --profile-directory takes, and is never shown in the interface. The display name is a field inside Local State and is what appears in the avatar menu and the profile picker.

Chrome writes Local State when it exits, and it writes the whole file. A script that edits that file while the browser is running will have its changes overwritten without warning, which is the most common reason a bulk renaming pass appears to work and then silently reverts. Edits to it have to happen with Chrome fully quit, and the profile list has to be treated as owned by the browser rather than by the script.

The folder numbering carries its own trap. Chrome allocates Profile 1, Profile 2 and so on in creation order, and deleting a profile does not free its number for reuse. A machine that has been through a few cycles of creation and deletion ends up with gaps, so scripts that assume the highest existing number plus one will eventually collide with an entry that already exists. Reading the existing folder names before choosing a new one costs one line and avoids the whole class of failure.

Count the cost before generating fifty of them

A freshly created profile takes only single digit megabytes on disk, which makes bulk creation look free. It is not, and the costs arrive later in three separate places.

Disk is the visible one. Profiles grow with use, mostly through caches, favicons and site storage, and a profile used daily for a year is measured in hundreds of megabytes or more. Multiply that by the number generated and the user data directory becomes one of the largest folders on the machine.

Memory is the one people actually feel. Every open profile runs its own network service state, its own extension service workers and its own renderer processes. Extensions in particular are stored and executed per profile, so an extension present in fifteen generated profiles is fifteen copies loaded when those profiles are open together.

Attention is the cost nobody budgets for. A profile picker with thirty entries, each labelled with a name chosen by a script months ago, is not a navigational aid. Finding the right one takes longer than the switching itself, and the usual response is to leave several open permanently, which returns the memory problem in a worse form.

The checks a homemade generator needs

A script that creates profiles reliably is short, but it is not a bare loop. Four checks separate one that works from one that has to be babysat.

The first is quitting Chrome before starting. Creating profiles while the browser is running means the new entries are written into a Local State file that the running process is also holding, and the last writer wins. Confirm no Chrome process is alive, then start.

The second is reading the existing profile folders instead of assuming a range. List the directories under the user data directory, collect the ones matching the profile naming pattern, and choose names that are not already taken. This is the check that stops a script overwriting a colleague's profile on a shared machine or silently reusing a number that was skipped after a deletion.

The third is waiting for each launch to finish before starting the next. Chrome writes the new folder and its Local State entry asynchronously, and firing ten launches at once produces a race in which some entries are lost. Launching, waiting for the profile folder to appear, then quitting cleanly, is slower per profile and far more predictable across twenty of them.

The fourth is deciding what the profiles are for at creation time rather than afterwards. A generated profile with no bookmarks, no pinned tabs and a machine assigned name is an empty room. If the point is that each profile is used for a specific account or client, the script should also set the startup pages and write the display name, because doing that by hand afterwards costs more than the creation it was meant to save.

Two smaller details are worth knowing. Passing the flag that suppresses the first run experience prevents the welcome tab from opening in every generated profile, which matters at scale. And a profile created this way is not signed into any Google Account, so anything that depends on sync has to be set up per profile by a person, which is the step no generator removes.

What bulk creation does not solve

Generating profiles solves exactly one problem, which is that the creation dialog is slow to repeat. It leaves every other problem in place.

Switching remains manual. Chrome's own documentation describes switching as selecting the profile and choosing from a list, and that list gets longer with every profile generated.

On your computer, open Chrome. At the top right, select Profile. Choose the profile you want to switch to. Source: support.google.com

Notifications remain undifferentiated. A message arriving in a chat tool looks the same regardless of which profile received it, so the separation that exists on disk does not exist on screen.

Window management remains the reader's job. Profiles do not remember which apps belong together, so a profile opened for one purpose still starts as an empty window and has to be rebuilt from bookmarks or memory every time.

And session state does not carry across. Profiles are separate precisely so cookies do not mix, which means every generated profile starts signed out of everything and each one has to be signed in by hand. For a script driven workload that is the point. For a person doing daily work across several accounts, it is the largest hidden cost in the whole exercise.

Where a script is the wrong tool entirely

There is a version of this request that a generator answers well. Quality assurance across many test accounts, a support team reproducing a customer's state, an agency handing each client a clean container: these are cases where the profiles are disposable, driven by code, and nobody switches between them by hand.

There is another version where a generator is a workaround for a missing feature. The profiles are not disposable, a person switches between them all day, and each one exists because two accounts of the same service cannot live in one browser window. In that case the bulk creation script solves the first ten minutes of the problem and adds to every day after it.

The second case has a structural answer. Instead of one browser copied many times, each web app gets its own window and its own session, so two accounts of the same service sit side by side without a profile between them. The boundaries that make this work are described on the Workspaces page, the services covered are listed under Supported apps, and the trade off against a subscription tool built on the same idea is set out in Compared with Wavebox.

What to change first

Before writing or buying a generator, answer one question: will a person switch between these profiles by hand every day. If yes, the number of profiles is the problem and generating more of them faster makes it worse, which is what SpaceDeck is built to change. If no, a loop over --profile-directory with a check for existing folder names is all the tooling the job needs.