Chrome multiple profiles generator: what it really does

Anyone who needs ten, twenty or fifty Chrome profiles quickly finds that the built-in dialog creates them one at a time. That is why "Chrome multiple profiles generator" scripts, notebooks and extensions exist. Under the hood, almost all of them do the same thing: they launch Chrome with one of two command-line flags, --user-data-dir or --profile-directory, pointed at a folder name that does not exist yet, and Chrome fills that folder with a fresh profile. Knowing which flag a generator uses tells you what it will create, where the data lands on a Mac, and what will break later. This guide walks through both flags as Chromium documents them (checked in October 2026), a minimal way to do it without any third-party tool, and the point where adding more profiles stops solving the actual problem.

What a profile generator actually produces

A Chrome profile is a folder. Chromium's User Data Directory documentation defines it plainly: the user data directory holds profile data such as history, bookmarks and cookies, and each profile is a subdirectory, often named Default, inside it. On a Mac, the default location for Google Chrome is ~/Library/Application Support/Google/Chrome.

That gives two different things a generator can create, and the difference matters.

Approach	Flag	What gets created	Shows in Chrome's profile menu
New profile inside the normal Chrome data	--profile-directory	A new subfolder next to Default	Yes
Entirely separate Chrome data	--user-data-dir	A whole new data directory with its own Default profile	No, it runs as a separate instance

The peter.sh list of Chromium switches, which is generated from the Chromium source, describes --profile-directory as selecting the directory of the profile to associate with the first browser launched. Point it at a name that does not exist and Chrome creates it. The same list notes a related switch, --ignore-profile-directory-if-not-exists, which does the opposite and refuses to create a missing profile.

--user-data-dir goes further. Chromium's Creating and Using Profiles page explains the basic process: create a folder for the new profile, launch the browser with --user-data-dir pointing at it, and if the folder is empty, the browser creates initial data. That page also says the approach is meant for running parallel instances, such as extension development or testing, and recommends the default profile for everyday browsing.

The built-in way, and why it does not scale

For a handful of profiles, Chrome's own menu is the right tool. Google's Chrome Help page describes the steps: select the profile icon at the top right, choose Add Chrome profile, then pick a name, photo and color scheme. Signing in with a Google Account sets the profile name to the account name automatically. The same page explains how to manage profiles through "Manage Chrome profiles", including a "Show on startup" option that lists every profile when a new browser session opens.

The trouble starts at volume. Each new profile walks through the same screens: a sign-in prompt, a choice of theme, sometimes a sync question. Twenty profiles means twenty passes through that flow, plus renaming and recoloring so the profiles are distinguishable in the menu. People who manage test accounts, social media accounts for several clients, or QA environments usually give up on the dialog after the fifth or sixth profile.

A generator removes the clicking but not the decisions. Every profile still needs a name that will mean something in three months, a sign-in, and a reason to exist. Generators that skip the naming step create folders called Profile 7 through Profile 26, which look identical in the menu until each one is opened and renamed. Deciding the naming scheme before generating anything is the single step that saves the most time later.

A minimal generator on macOS without extra software

There is no need to install anything to create profiles in bulk on a Mac. Chromium's guide to running Chrome with command-line switches shows the Mac method: quit Chrome, then call the binary inside the app bundle from Terminal. A loop over that call is a complete generator.

For new profiles inside the normal Chrome data, quit Chrome first, then run a loop like this in Terminal:

for name in client-a client-b client-c; do
  "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
    --profile-directory="$name" >/dev/null 2>&1 &
  sleep 3
done

Each pass opens a window on a new profile folder with that name. The folder names are internal; the name that appears in the profile menu is still set inside Chrome, under Customize profile, so the loop is only half the job.

For fully separate instances, the User Data Directory documentation describes an AppleScript wrapper. In Script Editor, a short script sets the path to the Chrome binary and a custom data folder, then runs Chrome with --user-data-dir pointing at it. Saved with the file format "Application", it becomes a clickable app that always opens that separate Chrome. Repeating that per folder gives a set of launchers, one per instance, which is what many paid "generators" sell.

Two practical limits apply. Chromium's documentation states that two running Chrome instances cannot share the same user data directory, so each launcher needs its own folder. And instances started with --user-data-dir do not appear in each other's profile menus, so switching between them happens in the Dock or with Command+Tab rather than inside Chrome.

What changed for automation in Chrome 136

Many profile generators exist to feed automation tools, which drive Chrome through its remote debugging port. That use changed in 2025. The Chrome for Developers blog post on remote debugging switches explains that from Chrome 136, --remote-debugging-port and --remote-debugging-pipe are no longer honored when pointed at the default Chrome data directory. They must be combined with --user-data-dir pointing at a non-standard folder, which uses a different encryption key so the main profile's data stays protected.

The reason given is security. The post describes cookie-theft tools that abused remote debugging against people's everyday profiles. For automation, Google recommends Chrome for Testing, which keeps the older behavior.

For anyone choosing a generator, this has two consequences.

• A generator that relies on remote debugging against the default profile no longer works on current Chrome. If a tool's instructions were written before Chrome 136, check this first.
• Separate data directories are now the expected setup for automated profiles. That favors the --user-data-dir approach, and keeps automated sessions away from the profile used for real work.

Checks before running a third-party generator

Generators found through search come as Python notebooks, shell scripts, browser extensions and paid desktop apps. Their descriptions tend to sound alike, so a few concrete questions separate them quickly.

1. Which flag does it use? The answer decides whether the new profiles appear in the normal profile menu (--profile-directory) or run as separate instances (--user-data-dir). A tool that does not say is worth reading line by line before running.
2. Where does it write folders? A generator that writes into ~/Library/Application Support/Google/Chrome is changing the profiles used for daily browsing. One that writes to its own folder keeps experiments apart. Backing up the Chrome folder before the first run costs a minute and removes most of the risk.
3. Does it ask for account passwords? Creating a profile never requires a password. A tool that wants Google credentials to "pre-sign in" each profile is handling far more than folders, and the safer pattern is to create empty profiles and sign in by hand.
4. Does it need to keep running? Some paid tools act as launchers and must stay installed for their profiles to open. Profiles created with plain flags keep working after the tool is removed, because they are ordinary Chrome folders.
5. Was it updated after Chrome 136? Anything built around remote debugging needs to account for the change described above.

A notebook hosted on an online service also deserves a second look. Code that runs on a remote machine cannot create folders on the Mac, so it can only produce a script to copy and run locally. Reading that script before running it is the whole security review.

Where bulk profiles stop helping

Profiles are good at one thing: keeping cookies, history, extensions and settings apart. They are less good at the work that usually prompted the search in the first place.

Every profile is its own window. Chrome opens each profile in a separate window with its own tab strip. Ten profiles in use means ten windows to cycle through, and the Mac sees them all as one app, Google Chrome. Mission Control can show them side by side, but there is no built-in way to label a window by client other than the profile's color and name in the corner.

Notifications blur together. Web notifications from every profile come from the same app in macOS Notification Center. Working out which client's inbox sent a message takes an extra step.

Memory adds up. Each open profile runs its own extensions and keeps its own pages loaded. Opening a dozen at once costs far more than a dozen tabs in one profile, because extension processes are duplicated per profile.

Profiles are not disposable without care. The Chrome Help page warns that removing a profile erases its bookmarks, history, passwords and other settings from the computer. A generator that creates profiles freely rarely helps clean them up.

None of this makes profiles the wrong tool. It means that past a certain count, the problem is no longer "creating profiles", it is "living with many signed-in identities at once".

Separate cookies without separate windows

For people whose real need is several accounts of the same web apps, such as three Gmail inboxes and two Slack workspaces, there is another way to get the isolation that profiles provide. App aggregation browsers on macOS give each web app its own cookie container inside one window, with the apps listed in a sidebar. The site publishing this guide is run by the maker of one such browser for the Mac.

Its Features page explains the model: each app keeps its own sign-in, so switching between them never signs anything out, and a second account is added by right-clicking an app and choosing to add it as another account with a separate session. Apps can be grouped by client or role through Workspaces, which keeps the "one identity per client" structure that profiles were standing in for. The Supported apps list covers the common services, and any URL can be added as an app.

According to its Pricing page, the free plan includes 1 workspace and up to 3 apps, while multiple accounts per service is a Pro feature at $7 per month, $60 per year, or $129 as a one-time purchase, with a 14-day trial that needs no account or card. This does not replace profiles for automation or extension testing. It replaces them for the everyday case of staying signed in to several accounts of the same tools.

What to do next

If the goal is automation or testing, skip third-party generators and loop over --user-data-dir with one folder per instance, which is also what Chrome 136 now expects. If the goal is a few dozen identities for daily work, create profiles with a naming scheme decided in advance, or keep those accounts in separate app containers with a tool such as SpaceDeck and leave Chrome's profiles for the cases they were built for.