Throwaway, burner, temporary browser: defined

A vendor sends you an invoice through an unfamiliar download portal. The link might be routine. It might hand the page a browser exploit, a hostile redirect, or a file you should never open on your daily machine. You need the document once. You do not want the session following you afterward.

Across the office, a contractor finishes a shift on a shared workstation. The next person should inherit the keyboard and screen, but none of the contractor's cookies, account state, permissions, or browsing history. That browser also needs to disappear, but for a different reason.

Three words, one instinct

People call the first browser throwaway. They call an identity-separated browser a burner. Teams usually call a resettable browser temporary. None of these phrases is a formal technical standard. Each one describes the job a person wants done.

The shared instinct is simple: I want this session to stop following me. The important question is what “following” means in that situation. It might mean untrusted code reaching your laptop. It might mean a purchase joining your normal advertising profile. It might mean a contractor's login surviving for the next shift.

Those stakes are different. A tool can solve one and fail the other two. Incognito mode can remove selected local records after a window closes. A VPN can change the network route. A cleanup script can reset the fields its author remembered. None of those properties alone proves that a browser session was fresh, isolated, and destroyed.

So the vocabulary matters less than the lifecycle. Ask what exists before the page opens, where the page executes, what identity signals leave the session, and what survives after close. Those four checks turn a fuzzy label into a testable requirement.

The throwaway browser

The throwaway-browser persona has one risky job. A support lead opens a customer-supplied attachment portal. A researcher follows an opaque redirect chain. A buyer checks a small storefront before placing an order. They do not plan to return. Their priority is containing what the page does during that single visit.

The obvious move is an incognito window. That changes what the local browser saves after the session. It does not change where the session runs. The page still executes JavaScript inside the browser on your device. A malicious download still reaches the local download path. A browser exploit still meets your installed browser.

This is the core limitation covered in the incognito mode security guide. Incognito is useful when you want less local history. It is not an execution boundary. Closing the window can clear selected browser state, but it cannot make local execution retroactively safe.

A credible throwaway browser therefore starts with no valuable state and keeps the risky page away from the everyday browser environment. It should contain downloads, scripts, cookies, and permissions inside the disposable session. Close must end the session itself, not merely hide its history entry.

A second local browser profile is not the same boundary. It can keep one set of cookies away from another, but both profiles still use the installed browser and local device. A virtual machine can create a stronger boundary, but only when the machine begins from a known image and is discarded after the job. The throwaway property comes from fresh creation and reliable destruction, not the window label.

• Before: no personal cookies, saved logins, or prior browsing state enter the session.
• During: untrusted page code runs inside an isolated environment, not the daily browser context.
• After: the browser instance and its state are destroyed when the job ends.

That is why “one time use browser” is often the clearest description. The same instance is not cleaned and handed back. It exists for the task, then stops existing.

The burner browser

The burner-browser persona is separating an activity from an established identity. A journalist researches a sensitive subject without mixing that work into a personal browser profile. A shopper checks a private purchase without feeding the session years of retail cookies. The page may be legitimate. The unwanted outcome is correlation.

That changes the requirement. The browser needs a clean cookie jar, fresh site storage, and no logged-in accounts from ordinary browsing. If the job also depends on network separation, the route and exposed IP must fit that requirement. The goal is a separate context, not merely an empty history list.

A VPN handles only part of that job. It encrypts and reroutes traffic through a VPN server. It does not remove the cookies already sitting in the browser. It does not replace the browser's stored permissions, cache, or fingerprint. The VPN, proxy, and browser isolation comparison explains that layer boundary in detail.

The burner label can also create false confidence. A fresh browser cannot keep an activity separate after you sign into the same personal account. A shipping address, payment account, email address, or deliberate file transfer can reconnect the activity. Session separation controls browser and network artifacts. It does not erase identifiers you choose to provide.

The right test is whether the burner begins without your normal identity context and ends without carrying its new context forward. If the next burner inherits the last one's cookies or local storage, it is a second profile, not a disposable identity boundary.

Keep the entire job inside that boundary. Opening personal webmail to collect a verification code creates a bridge. Moving a downloaded file into the daily browser creates another. Sometimes that transfer is necessary. Make it deliberate, and understand that the burner cannot separate identifiers once you move them across.

The temporary browser

The temporary-browser persona is often a team, not an individual. A contractor needs access for one shift. A library workstation serves a new visitor every hour. A kiosk supports a short sign-in flow. The owner needs a known starting state and a reliable reset after every user.

Here, convenience is not the main stake. Residual access is. A session cookie can reopen an account. A remembered permission can expose a camera or location choice. A downloaded document can remain on disk. A saved form value can reveal a name, address, or internal identifier to the next person.

Cleanup scripts look attractive because the browser stays installed. Their weakness is scope. Browser state is spread across history, cookies, cache, local storage, service workers, permissions, downloads, and profile settings. A script that clears history and cookies can still leave other artifacts behind. Every browser change also becomes another cleanup case to maintain.

A temporary browser should make reset the default outcome. The end condition might be a closed tab, a sign-out action, or an enforced session limit. Whatever triggers it, the next user should receive a fresh environment without relying on the previous user to clean up correctly.

Teams also need a visible boundary. Users should know which work belongs inside the temporary session. Administrators should know when it ends. A short-lived window without a dependable teardown rule is only temporary by intention.

A practical reset test uses harmless markers. Sign into a test account, grant a site permission, create local site state, and download a sample file. End the session exactly as a user would. Then start another session and look for every marker. If one returns, the reset is incomplete. That test is more useful than a policy document claiming the browser is temporary.

What actually delivers all three

All three jobs converge on Shield. Shield opens a page in an isolated browser off your device. Each session starts for one job and ends when you close it.

The phrase “browser that deletes itself” is useful shorthand, but it needs precision. The browser application or extension does not uninstall after every visit. The disposable browser instance is destroyed. The control surface remains available to spawn another fresh session.

Verification should follow the session from start to finish. Open the browser and confirm no prior account state appears. Check that risky content executes inside the isolated session. Close it and confirm the instance ends. Start another session and verify that the prior cookies, permissions, and history do not return.

Also define the end event before choosing a tool. A person closing a tab is different from a contractor losing access at shift end. A kiosk may need an enforced timeout because visitors walk away. The destruction guarantee should attach to the event your workflow can actually enforce.

1. Fresh at start: the job receives no state from the daily browser or previous disposable session.
2. Contained during use: page code, downloads, and site storage stay inside the session boundary.
3. Destroyed at close: the session ends without a manual cleanup checklist.
4. Fresh again: the next session proves that nothing carried forward.

That lifecycle is the common answer behind all three search terms. The deeper disposable browser explainer covers the category architecture. Anti-detect browsers serve a separate job and are not another name for this lifecycle.

Setting up the extension

Legba is a Chrome extension with two modes. Ghost gives you a private browser route. Shield opens a page in an isolated browser off your device.

Open the Shield section and add the extension. Choose Shield for the target page. The page runs off your device. Close the tab when finished. The session is destroyed.

$10 a month, or $100 a year. Free for 30 days. No card required.

Ready to choose? Compare the best disposable and temporary browsers.

Use the name that matches your job. Throwaway describes the risky task. Burner describes identity separation. Temporary describes the reset requirement. Then ignore the label and inspect the lifecycle. A session that starts clean, runs isolated, and ends completely is the property you were asking for.