Is it possible to have 2 chromes so I can use flash after 2020?

Title: Duplicating Chrome for Flash: Why Two Browsers Isn’t the Answer and What to Do Instead

In late 2020, Adobe officially killed Flash Player for browsers, bringing to an end a long era of web-based interactive content. Since then, countless users who grew up with Flash have faced a familiar, frustrating question: is there a way to keep two separate Chrome environments—one that stays “unupdated” to preserve Flash, and another that continues to receive security updates? The short answer is: not in any practical, safe way. The longer answer involves understanding how modern browsers work, what Flash dependencies actually require, and what viable alternatives exist for enjoying old Flash content today.

This article isn’t a hacky workaround guide. Instead, it provides a clear map of why two independent Chrome instances aren’t realistically achievable, what the real constraints are, and how you can approach preserving or migrating your Flash experiences responsibly and effectively.

1. Why “two Chromes” doesn’t work the way you expect

2. The architecture of Chrome is inherently single-profile-centric. When you launch Chrome, you’re entering a user profile that contains your bookmarks, extensions, settings, and data. The browser binary itself updates through the updater, and re-launching Chrome from the same user profile uses that same installed core.

3. Duplicating the executable doesn’t automatically create a second, isolated environment. If you copy the Chrome application folder and run the copy, macOS, Windows, and Linux all apply path-based expectations and shared resources. The result is often a separate process or a new tab—not an independent, non-updating browser instance engendering a locked-in version.
4. Chrome’s update mechanism is deeply integrated with Google’s services, signed binaries, and system permissions. Bypassing updates would require isolating the entire browser installation from the normal update pipeline, which is neither straightforward nor guaranteed to be secure.

In short, two parallel Chrome installations that behave as independent, unupdatable and updated-for-different-content forks are not a practical reality for most users. Even when you succeed at creating a second copy, both copies will likely end up sharing components, extensions, data directories, or update channels in ways that defeat the isolation you intended.

1. The practical problem: Flash is dead, officially and in the browser

2. Adobe ended Flash Player public updates, and modern browsers progressively disabled the Flash plugin. Chrome (and many other engines) removed NPAPI or Plug-in support for Flash many years ago. The Flash Player itself is no longer distributed by Adobe for mainstream consumers, and major browsers no longer support Flash content natively.

3. Even if you could forge a separate browser copy that runs an old Flash plugin, you would run into substantial security risks. An unupdated browser (or one that can run legacy plugins) becomes a magnet for attackers, as it lacks critical patches and mitigations present in current software.

4. Compatibility is another hurdle. Flash content relied on a combination of ActiveX/NPAPI plugin architectures (which modern browsers abandoned long ago) and Flash runtimes that require a specific sandboxing and permission model. Reproducing that environment safely within a separate browser is not straightforward or advisable.

5. What you can legitimately do today to access legacy Flash content

A. Use a purpose-built, offline Flash environment (without compromising security)

• Standalone Flash emulation environments reproduce the player’s behavior for viewing old content within a controlled sandbox. Projects like Ruffle (a Flash Player emulator) and similar open-source efforts aim to recreate Flash’s runtime behavior in modern browsers without needing the original plugin.
• How it works: you load Flash content (SWF files, games, animations) into an emulator that runs locally or within a modern browser sandbox. These projects are actively developed by communities concerned with preserving digital history, and they are designed with security in mind.
• Real-world approach: install a supported emulator, then host your own Flash content offline or via a local web server. This avoids the hazards of running an ancient plugin in an exposed environment while still delivering the interactive experience.

B. Use a protected, updated browser with Flash emulation support

• If you’re determined to keep a working environment for Flash-adjacent retro browsing, consider running Flash content exclusively through an emulator in a secure, sandboxed setup—separate from your day-to-day browsing. This minimizes risk while preserving access to legacy material.
• Avoid attempts to “hold” a Chrome version; instead, maintain a small, isolated instance dedicated to Flash content, using current security practices (updates applied to your main browser, not this isolated environment).

C. Rebuild your Flash library with modern equivalents

• Many classic Flash games and animations have been ported or recreated using HTML5, WebGL, or other modern web technologies. While not every item has a perfect 1:1 replication, the vast majority of well-known titles can be found or rebuilt with open-source tools.
• Practical steps:
• Make a list of your must-play Flash titles.
• Search for HTML5 or WebGL equivalents, ports, or remakes on reputable platforms.
• If you own the rights for certain content, consider commissioning or contributing to open-source ports or community remakes.
• This approach has the added benefit of future-proofing your collection against further browser changes.

D. Consider a controlled “offline arcade” setup

• For enthusiasts who want a dedicated retro-gaming feel, set up an offline machine or virtual machine with a minimal, hardened environment where you can run Flash emulation safely. Use a modern OS with a modern browser and the emulator layer to render Flash content, avoiding exposure to the broader web from the same environment.

• The right mindset: balancing nostalgia, safety, and practicality

• Nostalgia is powerful, but it shouldn’t steer decisions about security. There is a meaningful distinction between preserving historical media and maintaining an attack surface. The safest path is to decouple legacy content from everyday browsing and use purpose-built tools to experience it.

• Think in terms of preservation pipelines. Instead of chasing a perfect, decoupled Chrome instance, invest in a preservation setup: a local emulator, a curated offline repository of SWF files, and a lightweight frontend to launch content offline.

• The ethical and legal dimension matters too. Some Flash content is protected by licenses or belongs to creators who may have migrated or remixed their works. When handling archival material, consider licensing, attribution, and the available rights for preservation and recreation.

• Real-world implications and future directions

• The extinction of Flash in the browser has accelerated the emergence of dedicated emulation and porting efforts. This is a healthy development for digital heritage, mirroring how video formats and early web technologies were saved by archivists and communities.

• The industry trend is toward standards-based, future-proof formats (HTML5, WebGL, WebAssembly). If you’re building new content today, you should plan for long-term accessibility by avoiding proprietary plug-ins and leaning into standards that future browsers will support.

• For users with large Flash archives, institutions—mersistence libraries, museums, and universities—are increasingly establishing controlled environments to preserve and present legacy content. Joining or learning from these communities can provide both practical knowledge and curated access paths.

• Practical recommendations: a concise action plan

• Don’t attempt to maintain two independent Chrome installations to segregate Flash from updates. It’s not a reliable, secure approach.

• Explore Flash emulation options (notably Ruffle) and test a small subset of your content in a controlled environment.
• Build a personal preservation workflow:
• Inventory your Flash collection.
• Source or create HTML5/WebGL equivalents where feasible.
• Set up a local environment (offline, sandboxed) to run emulated content.
• If you must access Flash content online, use a dedicated, minimal browser profile that’s isolated from your everyday browsing and ensure all other software remains up to date.

• Stay informed about ongoing preservation projects. Subscribing to projects like Ruffle or digital preservation newsletters can keep you abreast of compatibility improvements, new ports, and best practices.

• Final consideration: what to take away

Preserving the ability to experience Flash content in a world where Flash is dead for browsers requires a shift from “duplicating a single browser” to embracing purpose-built, secure emulation and offline preservation workflows. The most reliable path is not to fight the architecture of modern browsers, but to work with it—using emulation, ports, and offline access to honor nostalgic works while maintaining modern security standards.

If you’re starting today, begin with a small, controlled experiment: install a Flash emulator on your computer, migrate one or two favorite titles, and test the experience in an isolated environment. Measure the effort, the fidelity of the playback, and the stability of the system. You may find that a thoughtfully designed preservation approach delivers a more satisfying, safer, and more future-proof experience than trying to hack together two parallel Chrome instances.