Playwright, Puppeteer and Cypress browser downloads on Mac

Playwright downloads real browsers to run its tests, and the Playwright browsers' size surprises most people. On an Apple silicon Mac, one Chromium build takes about 330 MB once unpacked, its headless shell about 190 MB, and WebKit about 280 MB. That's about 800 MB for one version of Playwright, before Firefox.

They don't live in your project. Playwright keeps them in one shared folder, ~/Library/Caches/ms-playwright. Puppeteer keeps its Chrome builds in ~/.cache/puppeteer, and Cypress keeps a copy of its test app for every version in ~/Library/Caches/Cypress. Deleting a project, or its node_modules, leaves all of them where they are.

Everything in these folders downloads again, so removing it loses nothing you made. The cost is time: the next install or test run fetches the browsers again. This post explains what each folder holds, why they grow, which tool removes old versions by itself, and what you can safely remove in Finder.

Where browser testing tools keep their downloads

Each tool pins the exact browser build it was tested against, downloads it once, and shares it between every project on your Mac. That saves a download per project, but it puts the files in your Library and your home folder rather than next to the code that uses them.

Tool	Folder	What it holds
Playwright, in any language	~/Library/Caches/ms-playwright	Chromium, Firefox, WebKit and FFmpeg, one folder per version
Playwright MCP	mcp- folders in the same place	Browser profiles that AI tools use, with their sign-ins
Puppeteer	~/.cache/puppeteer	Chrome for Testing and its headless shell, one folder per version
Cypress	~/Library/Caches/Cypress	The Cypress test app, one folder per version
Cypress	~/Library/Application Support/Cypress	The app's own data, which Cypress calls App Data
Selenium Manager	~/.cache/selenium	Drivers such as chromedriver, and browsers when a test needs one

Why the downloads live outside your project

Cypress's documentation gives the reason plainly: its test app is large and built for one platform, so it's kept in a global cache outside node_modules, where one download serves every project. Puppeteer moved its browsers to a shared folder in version 19 for a similar reason: to cache them once for every installation.

The side effect is that tidying your projects doesn't tidy these folders. If you've already cleared out old projects with the steps for removing node_modules folders, the browsers those projects used are still on your disk.

How to open these folders in Finder

In Finder, choose Go › Go to Folder, type the path, such as ~/Library/Caches/ms-playwright, and press Return. The tilde stands for your home folder.

The .cache folder in your home folder is hidden, because its name starts with a period. Go to Folder opens it anyway: type ~/.cache/puppeteer or ~/.cache/selenium in the same way.

To see how much a folder takes, select it and choose File › Get Info. The size appears once Finder has finished adding it up, which takes a moment for a folder full of browsers.

Where Storage settings counts them

Choose Apple menu › System Settings, click General, then Storage. These folders have no category of their own. They fall under System Data, which Apple describes as files that don't fit the listed categories, and Storage settings can't show or remove what's inside it.

That's the same in macOS 26 Tahoe and macOS 27 Golden Gate. It's also one reason System Data grows so large on a developer's Mac.

Playwright browsers size: what one install downloads

Playwright's install step downloads a set of default browsers, each into a folder named after the browser and a revision number. Playwright 1.64, the current version in October 2026, uses these:

Folder	What it is	When it's used
chromium-1248	Chrome for Testing 156	Tests that open a visible browser window
chromium_headless_shell-1248	Chrome's headless shell, the same version	Headless tests, which is Playwright Test's default
firefox-1555	Playwright's build of Firefox 157	Tests in Firefox
webkit-2370	Playwright's build of WebKit 27.2	Tests in WebKit, the engine behind Safari
ffmpeg-1013	FFmpeg, a small video tool	Recording videos of test runs
.links	A record of every Playwright install on the Mac	Deciding which browsers are still needed

Playwright's documentation says its browsers take "a few hundred megabytes of disk space", and its example shows Chromium at 281 MB, Firefox at 187 MB and WebKit at 180 MB. That example is old, and newer builds are larger. Here's what they take on one Apple silicon Mac, measured this month:

• Playwright's Chromium (Chrome for Testing 145)330 MB · Usually safe
• Playwright's Chromium (Chrome for Testing 151)356 MB · Usually safe
• Playwright's headless shell (145)187 MB · Usually safe
• Playwright's WebKit 26.0276 MB · Usually safe
• Playwright's FFmpeg2.5 MB · Usually safe
• Puppeteer's Chrome 144327 MB · Usually safe
• Puppeteer's headless shell (144)185 MB · Usually safe

Measured in October 2026 on an Apple silicon Mac, with the browsers of Playwright 1.58 and 1.62 and Puppeteer's Chrome 144. Firefox wasn't installed. Sizes change with every version, and Intel builds differ.

Why are there two Chromium folders?

Since version 1.57, Playwright runs on Chrome for Testing builds instead of plain Chromium. A test that opens a visible window uses the full Chrome build, and a headless test uses Chrome's headless shell, a smaller program without a window. A default install fetches both.

Playwright's install step has options for this. One fetches only the headless shell, for machines that never open a window, such as a build server. Another skips the shell, for projects that run Chrome's newer headless mode in the full build instead.

Why the folders multiply

Each Playwright release pins new browser revisions. A project on Playwright 1.58 uses chromium-1208, and one on 1.64 uses chromium-1248. While both projects are installed, both sets of browsers stay, because each project needs its own.

Here's a worked example. Three projects on three Playwright versions, each with Chromium, the headless shell and WebKit, keep three sets of about 800 MB each. That's about 2.4 GB before Firefox, for tests that may last have run months ago.

Google Chrome and Microsoft Edge aren't in this folder

Playwright can also test with the Chrome or Edge you'd use every day, through what it calls channels. It doesn't download them by default. If you ask its install step for one, it installs it in the usual place for apps on your Mac, replacing the copy you have, so it never appears in ~/Library/Caches/ms-playwright.

Playwright for Python, Java and .NET

Playwright's other languages use the same folder on a Mac. Playwright for Python's documentation names ~/Library/Caches/ms-playwright too, so a Python project and a Node.js project on the same Playwright version share one set of browsers.

How Playwright decides which browsers to keep

Playwright is the only one of these tools that removes old browsers by itself. Its documentation puts it simply: it "keeps track of the clients that use its browsers", and deletes a version once nothing needs it. The details explain why space sometimes comes back late, or not at all.

What the .links folder records

Every time Playwright's install step runs, it writes a small file into the hidden .links folder. The file holds the location of that copy of Playwright, such as a project's node_modules. Every copy counts separately: each project, each second checkout or git worktree with its own packages, and each Python environment with Playwright installed.

How to see which projects still hold browsers

Each record is a plain text file with a long name of letters and digits. To read one, open ~/Library/Caches/ms-playwright/.links with Go › Go to Folder, Control-click a file and choose Open With › TextEdit. It holds one line: the folder of a copy of Playwright, usually inside a project's node_modules.

If that folder no longer exists, the project or worktree is gone, and the browsers only it used go at the next install. Read the files, but don't edit, move or delete them: they're how Playwright knows what to keep.

A worked example from one Mac

On one Mac we looked at in October 2026, the folder held 1.3 GB and five records. One pointed to a project on Playwright 1.58, one to a git worktree on 1.62, and three to worktrees that had since been deleted.

The three dead records cost nothing extra: every browser folder left belonged to one of the two live ones. If the 1.58 project went, the next install anywhere would remove about 800 MB: its Chromium, headless shell and WebKit. FFmpeg would stay, because Playwright 1.62 uses the same revision.

When old versions are removed

Only while Playwright installs or uninstalls browsers. At that moment it reads each file in .links, checks which browser revisions that copy of Playwright needs, and deletes every browser folder nobody needs. A link whose project no longer exists doesn't count and is removed, so the browsers only that project used go too.

So deleting a project frees nothing in this folder straight away. The space comes back the next time any project runs Playwright's install step. That deletion is immediate and permanent: Playwright removes the folders itself, without the Trash.

When the clean-up is turned off

Two settings stop it. An environment variable, PLAYWRIGHT_SKIP_BROWSER_GC, turns it off, and since version 1.63 the install step has a --no-remove option that does the same for one run. Neither has an effect unless someone set it, usually in a build script.

Installs that keep browsers inside the project

Another environment variable, PLAYWRIGHT_BROWSERS_PATH, changes where browsers go. Set to another folder, such as one on an external drive, it must be set for both installing and running tests. Set to 0, it makes what Playwright calls a hermetic install, with the browsers inside the project's node_modules, so removing node_modules removes them too.

There's no window for either setting. They're read from your shell or a project's scripts, so check a project's setup before you go looking for its browsers.

How to remove Playwright's browsers

You have three routes: Playwright's own commands, Finder one version at a time, or Finder for the whole folder. Each suits a different situation.

Playwright's own uninstall command

Playwright's command-line tool has an uninstall command. Run in a project, it removes that project's entry from .links, then runs the same clean-up as an install: browsers no other copy of Playwright needs are deleted. With its --all option, it removes every entry, so every browser in the folder goes.

There's no button for it in any app. It's typed in Terminal, and it deletes without the Trash. Its install command also has a list option, which prints every installed browser with its version and location, for all the copies of Playwright on your Mac.

In Finder, one version at a time

Moving a single version folder to the Trash is safe, as long as no tests are running. Folders with older revision numbers belong to older Playwright releases, and the Date Modified column in list view shows when each was installed.

If a project still needs a version you removed, its tests stop with an error saying the browser's executable doesn't exist, and the message suggests running Playwright's install step. That step downloads the browser again. Until you empty the Trash, you can also put the folder back.

In Finder, the whole folder

If you've finished with browser testing on this Mac, move the whole ms-playwright folder to the Trash. Every browser goes, along with .links and any Playwright MCP profiles, which signs AI tools' browsers out of every website. Each project downloads its browsers again the next time its install step runs.

Can you delete only the .links folder?

Don't. It looks like a tidy-up, because the folder is small, but it's the only record of which projects use which browsers. The next install then sees only its own project and deletes browsers other projects still need, which they then download again.

Way	What it removes	When it comes back	Can you undo it?
An install step, by itself	Versions no copy of Playwright needs	Never needed again	No
The uninstall command	That project's browsers, unless another project uses them	At the project's next install	No
The uninstall command with --all	Every browser in the folder	At each project's next install	No
One version folder to the Trash	That version	At the next install that needs it	Yes, until you empty the Trash
The whole folder to the Trash	Every browser, the record and MCP profiles	At each project's next install; sign-ins don't	Yes, until you empty the Trash

Playwright MCP profiles and AI coding tools

AI coding tools can drive a browser through the Playwright MCP server, to check a page they've just changed or to read documentation. That browser keeps a profile on disk, so it stays signed in between sessions. More on what these tools store is in how AI coding tools fill a Mac.

What's in an mcp- folder

Playwright MCP keeps each profile in ~/Library/Caches/ms-playwright, in a folder whose name starts with mcp-, then the browser's name and a code for the project. Its documentation says the code comes from the AI tool's workspace, so each project gets its own profile automatically.

A profile is like your own browser's: cookies, sign-ins and website data, plus that browser's own cache. Many projects means many profiles.

Is it safe to delete an mcp- folder?

Nothing breaks. Playwright MCP's documentation says you can delete the profile between sessions to clear its state, and it creates a new, empty one next time. The cost is that the browser your AI tools control is signed out of every website it used, and you sign in again where it needs to.

Close the AI tool's browser first, or end the session, so the profile isn't in use.

Profiles that never reach the disk

Playwright MCP has an isolated mode, which keeps the profile in memory and saves nothing when the browser closes. It can also be pointed at a profile folder of your choosing, which then lives wherever that is. Both are set in the AI tool's configuration for the MCP server.

Does Playwright remove old profiles?

No. Playwright's clean-up only touches folders named after browsers, such as chromium- and webkit-, so mcp- folders stay until you remove them. A profile for a project you deleted long ago is still there.

Puppeteer's Chrome downloads

Puppeteer controls Chrome from Node.js. When you install the puppeteer package in a project, it downloads the Chrome for Testing version that release was built for, plus Chrome's headless shell, into ~/.cache/puppeteer.

What's inside the puppeteer folder

You'll find a chrome folder and a chrome-headless-shell folder. Inside each is one folder per version, named after your Mac's chip and the version number, such as mac_arm-144.0.7559.96 on Apple silicon. Firefox is downloaded only if a project asks for it, so most Macs have no firefox folder.

Puppeteer's installation guide puts the Chrome download at about 170 MB on a Mac. Unpacked it takes more: about 330 MB for Chrome 144 on an Apple silicon Mac, plus about 185 MB for its headless shell.

Why old Chrome versions pile up

Each Puppeteer release pins one Chrome version. Upgrading Puppeteer in a project downloads the new Chrome next to the old one, and Puppeteer's install step only adds: unlike Playwright, it keeps no record of which projects use which version, and it never removes one.

So every Chrome version any project of yours has used is still there. Four upgrades over a year can mean four sets of about 500 MB each.

Puppeteer's programming interface does have a trimCache method, which a script can call to remove every Chrome version except the one its Puppeteer release uses. Its documentation warns that it doesn't check whether other projects on the Mac still need the versions it removes.

Removing old versions in Finder

Open ~/.cache/puppeteer with Go › Go to Folder, then open chrome and chrome-headless-shell. Move the folders for versions you no longer use to the Trash, starting with the lowest version numbers.

A project that still needs a version you removed fails to start Chrome, with an error that it couldn't find that version. Reinstalling the project's packages downloads it again, and so does Puppeteer's own browsers install command.

One catch: Puppeteer's download runs as an install script, and its documentation notes that several package managers now block install scripts by default. With those, reinstalling the packages skips the download, and only Puppeteer's browsers install command brings Chrome back.

Removing the whole folder

Moving the whole puppeteer folder to the Trash is safe too. Every project that uses Puppeteer downloads its Chrome again when its packages are reinstalled.

Puppeteer also has a clear command, which removes every installed browser from the folder. It asks you to type yes first, and it deletes permanently, without the Trash.

Projects that download nothing

The puppeteer-core package is Puppeteer without the browser: its documentation says it doesn't download Chrome when installed. Projects that use it point at a Chrome already on your Mac. A project can also set its own cache folder in a Puppeteer configuration file, and then its browsers are wherever that file says, often inside the project.

The Cypress test app cache

Cypress works differently. It doesn't download browsers; it uses the Chrome, Firefox or Edge already on your Mac, and its own built-in Electron browser. What it downloads is the Cypress app itself, the program that runs your tests.

One folder per Cypress version

When a project installs the cypress package, Cypress downloads the matching version of its app into ~/Library/Caches/Cypress, in a folder named after the version, such as 15.0.0. Its documentation says the cache "accumulates a binary per Cypress version you've used", and that this can quietly take up space on developer machines.

Cypress doesn't publish a current size, but its download for version 16.1.1, the current release, is about 220 MB for Apple silicon, compressed. Unpacked it takes more: the example in Cypress's command-line documentation shows two older versions at about 425 MB and 436 MB each. Several versions side by side add up quickly.

Cypress's own cache options

Cypress's command-line tool has a cache command with four options, all typed in Terminal:

• path prints where the cache is.
• list shows each version in the cache and when you last used it, and with its size option, how much each takes. Cypress warns that working out sizes can be slow.
• prune removes every version except the one the current project has installed.
• clear removes every version. Cypress then needs its install step before it runs again.

Prune is the one that fits most Macs, but note what "current" means: the version installed in the project where it runs. Other projects that use other versions download theirs again when they next need them.

Removing versions in Finder

The Finder route is the same as prune, done by hand. Open ~/Library/Caches/Cypress, sort by name, and move the folders for older versions to the Trash. Keep the versions your active projects use, and quit Cypress first.

If a project needs a version you removed, Cypress says so when you open it. Reinstalling the project's packages downloads it again, and so does Cypress's own install command.

Cypress's app data

~/Library/Application Support/Cypress is a separate folder, which Cypress calls its App Data. Cypress's uninstall instructions list it among the things to remove when you uninstall Cypress, because it stays behind otherwise. While you still use Cypress, leave it alone.

Cypress's WebKit support uses Playwright's folder

Cypress's experimental WebKit support needs the playwright-webkit package installed in the project. That package's install step downloads WebKit through Playwright, into ~/Library/Caches/ms-playwright, so a Cypress project can be the reason a WebKit folder appears there.

Other places test browsers end up

Playwright, Puppeteer and Cypress are the large ones on most Macs, but they aren't the only tools that download browsers.

Selenium Manager

Selenium Manager, built into Selenium, downloads the driver a test needs, such as chromedriver or geckodriver, and a browser when needed, into ~/.cache/selenium. Since Selenium 4.11, its Chrome downloads are Chrome for Testing builds, like Puppeteer's.

It tidies up after itself. Its documentation says it removes driver and browser versions that haven't been used in over 30 days. Anything you remove downloads again at the next test run.

One file there is yours: se-config.toml, an optional settings file you may have written. It isn't a download, so keep it when you clear the folder's contents.

Tests that run in a container

If you run browser tests in a container, such as Playwright's Docker image, the browsers are inside the image. They take space in your container tool's disk, not in these folders, and they're removed with the image. For Docker Desktop, what its disk image holds explains where that space goes.

Older projects with their own copies

Some setups keep browsers inside the project: Playwright's hermetic install, a Puppeteer configuration file that sets a cache folder in the project, or a Cypress cache folder set by an environment variable. Those copies are removed with the project, and they don't show up in the shared folders.

Tool	Removes old versions by itself?	Its own way to clear	Downloads again
Playwright	Yes, when an install step runs	Uninstall command, with --all for everything	At the next install step
Puppeteer	No	Clear command, for everything	When packages are reinstalled
Cypress	No	Prune for old versions, clear for everything	When packages are reinstalled
Selenium Manager	Yes, after 30 days unused	A clear-cache option	At the next test run
Playwright MCP profiles	No	None; delete the folder	A new empty profile at the next session

Choosing what to remove

Nothing in these folders is your own work, apart from the sign-ins in MCP profiles and Selenium's settings file. The question is only whether you'll wait for a download later.

A quick way to decide

If	Then
You no longer run browser tests on this Mac	Move the whole folders to the Trash; nothing breaks until you test again
You deleted projects that used Playwright	The next Playwright install anywhere removes their browsers
You deleted projects that used Puppeteer or Cypress	Remove their versions by hand; nothing else will
Several Playwright versions sit side by side	Move your projects to one version, or remove old version folders
An AI tool's browser is signed in to sites you need	Keep its mcp- profile
You test on a slow or metered connection	Keep the versions your active projects use

What you'll see if a project needs something you removed

Nothing fails until a test starts. Then each tool says what's missing and how to get it back:

• Playwright stops with an error that the browser's executable doesn't exist, and suggests running its install step.
• Puppeteer says it could not find Chrome, with the version it wanted.
• Cypress says no version of Cypress is installed in its cache folder, and suggests its install command.
• Selenium downloads what's missing by itself, so the only sign is a slower first run.

In each case the download comes back the way it first arrived, when the project's setup runs the tool's install step. If you moved the folder to the Trash and haven't emptied it, putting it back works too.

Mistakes to avoid

• Removing only the .links folder. The next Playwright install then deletes browsers other projects still use.
• Removing files inside a version folder. Remove a version whole or not at all; a half-removed browser can still look installed and fail when it starts.
• Removing browsers while tests run. Stop the test runner, and close Cypress and any AI tool's browser, first.
• Expecting node_modules to take the browsers with it. Only hermetic installs keep them there.
• Forgetting the tools' own commands are permanent. Playwright's uninstall, Puppeteer's clear and Cypress's prune and clear skip the Trash.
• Pasting cleanup commands from a web page. A command that deletes the wrong folder can't be undone, and nothing here needs one.

Keeping them from coming back

Keep your projects on the same Playwright, Puppeteer and Cypress versions where you can, so they share one download. Install only the browsers you test with: Playwright's install step accepts browser names, and a project that never tests WebKit doesn't need it.

After upgrading Cypress, remove the previous version's folder once no other project uses it. Check these folders' sizes with Get Info every few months, because none of them shrink unless something removes old versions.

Moving the downloads to another disk

Each tool can keep its downloads elsewhere, such as on an external drive, but only through environment variables or configuration files: PLAYWRIGHT_BROWSERS_PATH for Playwright, a cache folder in Puppeteer's configuration file, and CYPRESS_CACHE_FOLDER for Cypress. There's no window for any of them.

Cypress warns that its setting must be present every time Cypress starts, not only when it installs, and the same goes for Playwright's. A drive that isn't connected means the tool can't find its download. Removing these files doesn't make tests or your Mac faster; it only gives the space back.

How the app does it

Wombit explains these folders like everything else on your disk. Select one in the map, the app's home screen, to see what it is, how safe it is to remove and what removing it costs, from the catalog's entries.

The catalog lists each Playwright version folder, the MCP profiles and the folder as a whole separately, so you can choose one without the others.

• ~/Library/Caches/ms-playwright/*

  Playwright browsers

  Chromium, Firefox and WebKit builds that Playwright downloads to run browser tests, in one folder per browser version.

  Usually safe · Moves it to the Trash

• ~/Library/Caches/ms-playwright/mcp-*

  Playwright MCP browser profiles

  Browser profiles that the Playwright MCP server keeps for AI tools, including the websites they're signed in to.

  Usually safe · Moves it to the Trash

• ~/Library/Caches/ms-playwright

  Playwright folder

  Playwright's folder for the browsers it tests with, the profiles its MCP server uses, and its record of which projects use each browser.

  Usually safe · Moves it to the Trash

• ~/.cache/puppeteer

  Puppeteer browsers

  Chrome builds that Puppeteer downloads for the projects that use it, shared between projects.

  Usually safe · Moves it to the Trash

• ~/Library/Caches/Cypress

  Cypress app cache

  Copies of the Cypress test app that Cypress downloads, one for each version your projects have installed.

  Usually safe · Moves it to the Trash

• ~/.cache/selenium/{chrome,chromedriver,edge,firefox,geckodriver,msedgedriver}

  Selenium Manager drivers and browsers

  Browser drivers and browsers that Selenium Manager downloads automatically when your Selenium tests need them.

  Safe · Moves it to the Trash

Playwright's, Puppeteer's and Cypress's folders are Usually safe: they come back, at the cost of a download, so they never start checked and never count toward the safe-to-remove total. Selenium Manager's downloads are Safe, because Selenium fetches them again by itself at the next test run.

Checking an item in Cleanup moves it to the Trash after the review sheet, where you can put it back, and every run is logged.

Seeing what these downloads take is free. Moving them to the Trash is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.