What Private Browsing Does and Does Not Do
Understand which local browsing records private windows limit, what remains visible to websites and networks, and when to use a separate profile instead.
Want the structured docs for Fingerprint?
This article lives in the editorial library. For step-by-step setup, reference material, and ongoing updates, jump into the docs section.
Private browsing creates a temporary local browsing session. It is useful when a person wants to avoid mixing a short task with the history, cookies, and signed-in state of a normal browser profile. When the last private window closes, the browser removes much of the site data created by that private session. Downloads, bookmarks, account records held by a service, and activity visible outside the browser do not disappear with it.
That boundary is the important part. A private window changes how the browser retains local session data. It does not make a person anonymous, replace a network privacy tool, prevent a website from seeing requests, or erase information already sent to an account. Chrome and Firefox both state these limits in their user documentation. The exact controls and labels vary by browser and version, so the browser's current help page remains the final reference for a specific device.
Treat the private window as a local session boundary
A normal profile carries state from one visit to the next. It can keep history, site cookies, local storage, permissions, saved form information, extensions, and active account sessions. That continuity is useful for ordinary work, but it can also connect a short task to state that the task did not need. A private window starts with a separate temporary session so that the task does not automatically reuse most of the profile's site state.
This separation is local to the browser. It can help on a shared computer when someone needs to sign in briefly without leaving the account open in the normal profile. It can also help when checking how a public page behaves without an existing site session, or when completing a one-time task that should not enter the normal browsing history. The user should still confirm that the device itself is appropriate for the task and that other people cannot access files or screens while the session is open.
The boundary lasts until the private session ends. In browsers that group private windows into one session, opening a second private window may share cookies and sign-in state with the first. Closing one window while another remains open may therefore keep that temporary state alive. A clean ending requires closing every private window associated with the session, then using the browser's private-window or private-tab view to confirm that none remain.
Private mode does not create a durable work area. Drafts held only in a page, unsent form entries, temporary site data, and an authenticated session can be lost when the windows close. Save intended work to an approved location before ending the session. Do not keep a private window open for days as a substitute for a managed profile, because an update, crash, device restart, or accidental close can end the temporary state without a useful recovery path.
The browser privacy basics guide places this local boundary alongside permissions, network visibility, extensions, and retention. Those other surfaces continue to matter inside a private window. Private browsing changes one part of the privacy decision; it does not replace the decision.
Know what closes with the session
Browsers generally avoid adding pages opened in private mode to the normal browsing history. They also keep the private session's cookies and site data separate from the normal profile and remove that temporary state when the private session fully closes. This makes the next normal browsing session less likely to inherit the private session's sign-in or site preference state.
The phrase "site data" covers more than one item. A site may use cookies, local storage, IndexedDB, caches, and other browser-managed storage during a session. The browser may need this state while the private windows remain open so that navigation, authentication, shopping carts, and consent choices work normally. Private browsing is not a stateless mode. It is a temporary state whose local lifetime is tied to the private session.
Information typed into forms is not normally added to the browser's long-term autofill history merely because it was entered in a private window. That does not stop the receiving website from processing or storing submitted information. A delivery address sent to a merchant, a message sent to a support service, or a document uploaded to an account has left the local form. Closing the window cannot recall it.
Searches and page visits may be absent from the browser's normal local history after closure, but the search service and visited site can still hold their own records. If the user signs in, those records may be associated with the account according to the service's settings and retention policy. If the user does not sign in, the service still receives the network request and the information needed to respond.
Permissions need separate attention. A private session can request camera, microphone, location, notifications, clipboard, or other capabilities when a page needs them. Browser behavior for remembering those decisions varies. The user should grant only what the current action requires, watch for the browser's active-use indicators, and stop the capability when the task ends. Permission state should serve the requested function rather than become a broad collection surface.
Private mode may block or limit some third-party storage by default, depending on the browser and current settings. That can reduce one kind of cross-site state, but it is not a guarantee that every third-party request is blocked. Embedded video, payments, identity, maps, fonts, and support services can still receive requests when their components load. Use the browser's tracking protection and site controls for those relationships instead of assuming that the private label removed them.
Separate retained files from browser history
Downloaded files remain on the device after the private session closes. This is one of the most important practical limits. A statement, image, installer, archive, or exported report is stored by the operating system in a download location chosen by the user or browser. Removing the download entry from a browser list does not necessarily remove the file, and closing a private window does not delete it.
Before downloading on a shared or managed device, decide where the file is allowed to live, who can open that location, and when it should be removed. Use an approved encrypted or access-controlled destination when the content requires it. After the task, verify the actual folder rather than relying on the browser's history view. Also check whether the file was opened by another application that maintains recent-item lists, autosave data, thumbnails, or temporary copies.
Bookmarks also persist when a user deliberately creates them in a private session. That is useful when the page should become part of the normal profile, but it crosses the temporary boundary. A bookmark can expose the page title or URL to anyone who uses the profile, and browser synchronization can copy it to other devices. Create one only when durable retention is intended.
Printing and sharing create similar durable outcomes. A print job can remain in a queue or produce paper; a share action can send the page to another application, person, or cloud account. Screenshots, clipboard content, password-manager entries, and files saved through a page are controlled by other components. Private browsing cannot delete data that another application or service owns.
The operating system and device owner may also retain information outside the browser. Endpoint security tools, parental controls, device management, backup software, DNS services, routers, and network logs can observe or retain parts of an activity according to their role. Private browsing does not change those systems. On a managed device, use the published device policy to decide whether a task is appropriate; do not infer privacy from the absence of a browser history entry.
For browser-managed cookies and site state in a normal profile, use targeted deletion rather than opening every task in private mode. The cookie management guide covers session cookies, retained state, and per-site cleanup. A clear retention rule is more reliable than treating private mode as an automatic cleanup tool for every kind of data.
Understand who can still see the activity
The website receives requests from a private window in the same basic way that it receives requests from a normal window. It can see the requested URL, request timing, protocol information, an address visible at its network edge, and information the browser exposes so the page can render and function. Private mode does not remove these requests or tell the site to forget them.
Signing in gives the service a direct account relationship. Pages viewed, searches made, messages sent, purchases completed, and settings changed may be stored with that account. Signing out before closing the window can be useful on a shared device, but it does not delete completed account activity. Account deletion, history controls, purchase records, legal retention, and support records follow the service's own policy.
A workplace, school, Internet provider, network operator, or device administrator may be able to observe connection metadata or apply policy. Encrypted transport protects content in transit from parties that do not terminate the connection, but it does not hide the destination from every participant. A private window does not alter the network route, DNS configuration, proxy, virtual private network, or organization policy by itself.
Extensions are another participant. Browsers often restrict extensions in private mode unless the user explicitly permits them, but the exact behavior is browser- and extension-specific. An allowed extension may be able to read or change pages according to its permissions. Review the extension list before using a private session for sensitive work, and do not grant private-window access merely to make a task convenient.
Web applications may observe capabilities needed for layout, media, accessibility, security, or compatibility. Private mode is not a promise that those browser characteristics become unavailable. Avoid products or workflows that claim anonymity merely because a private flag is present. Evaluate the actual data flow: the service, account, permissions, network path, embedded providers, and retained outputs.
For network-specific decisions, the WebRTC network identity guide explains why application media paths and network controls need their own review. Private browsing and network routing solve different problems. Combining their names into one privacy promise makes the result harder for a user to verify.
Choose the session that matches the task
Use a private window for a short local separation task. Examples include signing in temporarily on an otherwise trusted shared device, checking a public page without normal profile cookies, or completing a one-time workflow that should not remain in the normal browser history. Keep the task narrow, avoid durable downloads unless intended, and close every private window when it finishes.
Use a normal profile when continuity matters. Saved work, repeat sign-in, accessibility preferences, trusted extensions, offline data, and recovery are easier to manage in a profile with an explicit owner and retention policy. Clear one site's data when only that relationship needs to reset. Deleting all profile state or repeatedly using private windows can create avoidable sign-in and recovery work.
Use a separate profile when the separation must survive browser restarts. Work and personal accounts, different organizations, controlled testing, and distinct extension sets usually need durable boundaries. A profile can have its own cookies, permissions, bookmarks, settings, and lifecycle without pretending that the work is temporary. The profile management guide describes ownership, storage, updates, and retirement for those longer-lived boundaries.
Use a separate operating-system account when people share a device and need stronger local separation. Browser profiles still live under one operating-system user and may share access to downloads, applications, process visibility, backups, or administrative controls. Separate system accounts can make file ownership and login boundaries clearer, subject to the device's management policy.
Do not use private browsing as the deciding control for high-risk tasks on an untrusted device. A private window cannot establish that the operating system is free from monitoring, that the keyboard and screen are private, or that downloaded files will be removed. Use a trusted device and an approved workflow. If the device cannot meet the task's requirements, changing the browser window type is not a sufficient correction.
Before opening the window, answer four questions. Does the task need existing profile state? Must any result remain after closure? Which service or account will retain the submitted action? Which person or system can observe the device and network? A private session fits when existing state is unnecessary, durable outputs are limited and intentional, service-side retention is understood, and the device is trusted for the task. If the answer to any question is unclear, resolve it before entering credentials or opening a sensitive file. This short check prevents the private label from becoming a substitute for account, device, or network review.
Record exceptions at the layer that owns them. If a file must remain, place it in the approved destination and assign a deletion date. If an account action must remain, use the service's history and access controls. If a site needs a permission, grant it for the visible task and revoke it afterward when the browser supports that choice. The private window then has one clear job: keeping temporary local browser state out of the normal profile.
The right choice can be written as a simple rule: use private mode for temporary local state, a profile for durable browser separation, an operating-system account for user separation, and network or account controls for the systems that own those layers. This avoids asking one setting to solve unrelated privacy problems.
Close and verify the session
Finish the task inside the service first. Save intended work, submit necessary forms, and confirm visible results. If the user signed in on a shared device, sign out and verify that the service returns to a signed-out state. Closing a window without confirming completion can leave uncertainty about whether a message, upload, purchase, or account change succeeded.
Review durable outputs. Check the downloads folder, bookmarks, screenshots, clipboard, print queue, password manager, and any application used to open or share a file. Keep only the outputs required by the task. When deletion is appropriate, remove the item from the system that owns it and verify the result there.
Close every private window. On mobile devices, remove all private tabs from the browser's private-tab view rather than only leaving the app. On desktop systems, confirm that no private browser window remains. The exact interface varies, so use the browser's current window or tab indicator instead of relying on memory.
Reopen a new private session only when a check is necessary. Confirm that the previous site's authenticated state and temporary preferences are absent. Do not test by exposing sensitive information again. A visible signed-out page or missing temporary preference is usually enough to confirm that the local session ended.
Finally, separate local confirmation from broader deletion. A clean new private session shows that temporary browser state did not carry forward. It does not prove that a website, account, network, downloaded file, or other application deleted its records. Use each owner's controls for those records and retain only the minimum confirmation required for the task.
Public sources
Related Articles
Take BotBrowser from research to production
The guides cover the model first, then move into cross-platform validation, isolated contexts, and scale-ready browser deployment.