Throwaway browsers for tests and screenshots
A disposable browser with no login and no memory, launched fresh and discarded. Right for rendering a public page, a screenshot, or a test, and wrong the moment a login appears.
Not every job needs a logged-in session or a browser that remembers anything. When the task is rendering a public page, grabbing a screenshot, or driving a dev server's UI in a test, reach for a throwaway browser.
What it is
A browser launched fresh for one run and discarded. No login, no saved profile, no sessions to protect. Most automation libraries ship their own bundled browser for exactly this, so there's nothing extra to install or keep running. A clean slate every time is the feature, not a limitation.
Best for
Rendering or screenshotting a public page. Automated tests and continuous integration, where each run should start from nothing. Driving a local dev server's UI to confirm a change works.
Skip it the moment a login is involved
A throwaway browser starts signed out of everything, by design. If the task needs auth, this is the wrong surface: use a logged-in browser from Part 2 instead of bolting a login onto something built to forget. That's the whole line between this and Part 2.
Because it has none of the machinery of the other surfaces, no persistent profile, no stored logins, no window to keep alive, it's also the simplest to reason about. When a job genuinely needs nothing remembered, that simplicity is worth choosing on purpose.
Next up, Part 6: what to do when a site is built to keep automation out.