The Online Privacy Guide: Practical Threat Models for Browser-Based Work in 2026

Online privacy used to be a niche topic discussed mostly by people with a professional reason to care. That’s changed. In 2026, almost everyone works with data that has some privacy weight — client names, financial records, medical scans, internal company documents — and almost everyone relies on a mix of tools whose trust model they’ve never examined.

This is the comprehensive version of what I’d tell a careful professional who’s trying to be deliberate about their privacy practices. It covers threat modeling, the tools that actually help, and the everyday decisions where privacy compounds (for you or against you).

Part 1: the threat model first

“Privacy” isn’t one thing. What you protect against changes the answer to “is this tool safe.” Three common threat models worth naming:

Casual curiosity: anyone who doesn’t have a specific interest in you but might happen to see your screen, get access to an old device, or look at a shared computer. Defense: lock screens, clear history, cover your webcam. Doesn’t require sophisticated tools.

Data broker / third-party aggregation: commercial entities who profile you by combining data from many sources — ads, tracking scripts, data leaks, purchased data. Defense: use a privacy-respecting browser, block trackers, minimize account creation, assume any free online service monetizes your data.

Targeted attacker: a specific person (an ex-partner, a stalker, a competitor, a state actor) who is trying to find out what you’re doing. Defense: much harder. Requires careful attention to metadata, compartmentalization, and often professional-grade operational security.

Most everyday privacy practice aims at the first two threat models. The third requires a different class of care and is beyond the scope of this guide.

Part 2: the “where does my data go” question

Every time you use an online tool, one question matters: does the data go to a server, or does it stay on your device?

The distinction is structural, not marketing:

• Server-side tools (most “Smallpdf-alike” services, most online converters, most AI tools): you upload something, a server processes it, and you download the result. The server has your data — either briefly or permanently, depending on their policies. This is fine for public data, problematic for sensitive data.
• Browser-based tools (tools that declare they run in the browser and have no upload): your data stays on your device. The browser executes JavaScript/WebAssembly that processes the file locally. Nothing is transmitted.

You can verify which category a tool falls into with the browser’s developer tools. Open DevTools, go to the Network tab, use the tool, and watch for outbound requests. If no request carries your input, the tool is genuinely client-side.

This verification is the single most important skill for online privacy. It takes 30 seconds and replaces reading a privacy policy with observing actual behavior.

For a full walkthrough of what leaks with specific file types, see Why Your PDF Tool Should Run in the Browser and Client-Side Image Compression.

Part 3: passwords and authentication

Passwords are the first line of defense for almost everything. In 2026, the rules are:

1. Length over complexity. 16 random characters, 6+ Diceware words, or anything with 80+ bits of entropy. Complexity rules like “must have a symbol” were NIST guidance 15 years ago and are actively discouraged now.
2. Unique per account. The biggest practical threat isn’t someone cracking your password; it’s someone buying a database of leaked passwords from a service you forgot you signed up for in 2019 and trying them against your other accounts.
3. Stored in a password manager. Bitwarden, 1Password, KeePassXC. You remember one master passphrase; the manager remembers everything else.
4. Passkeys where available. FIDO2/WebAuthn replaces passwords entirely. Apple, Google, Microsoft, GitHub, PayPal all support them. Use them.
5. Two-factor authentication for anything that matters — authenticator app, not SMS (SMS 2FA has been bypassed via SIM-swap attacks for years).

Our Password Generator produces random passwords using a cryptographically secure RNG, entirely in the browser — the password is never transmitted. For checking whether an existing password is strong enough, the Password Strength Checker estimates entropy and flags common patterns.

Full rationale for the current thinking on password strength is in Password Strength in 2026.

Part 4: encryption for files you share

If you need to send a sensitive file to someone (contract, tax documents, medical records), the secure path is:

1. Encrypt the file with a strong passphrase.
2. Send the encrypted file through any channel (email, Slack, Google Drive — doesn’t matter).
3. Send the passphrase separately through a different channel (a phone call, a text, an in-person handoff).

The separation of channels matters. A compromise of one channel (someone reading your email) doesn’t compromise both halves.

Our AES Encrypt/Decrypt uses AES-256 with a passphrase-derived key, entirely in the browser. The encrypted file can be shared safely; only someone with the passphrase can decrypt it.

For recipient convenience, the encrypted output is typically a single file with a distinctive extension. If your recipient isn’t technical, walk them through decryption once — after that, they’ll know the pattern.

Part 5: what not to paste into online tools

There’s a category of data that shouldn’t go into any unvetted online tool, full stop:

• Credentials: API keys, tokens, private keys, database connection strings, OAuth secrets, webhook secrets.
• Personal data of others: customer exports, employee records, patient data, student records.
• Company confidential: source code of proprietary systems, internal architecture docs, financial projections, board materials.
• Regulated data: HIPAA (health), PCI (payment card), any personal data that would trigger a breach notification requirement.

The common thread: if an exfiltration of this data would appear in a breach notification, it shouldn’t be pasted into a web form whose server behavior you haven’t verified.

The full rationale and safer-alternative list is in Never Paste This Into a Random Online Tool.

Part 6: working with documents

PDFs and images are the most common sensitive file types in office work. Both have in-browser tools that genuinely never upload — compressing, splitting, merging, password-protecting all happen locally.

Things specific to PDFs:

• Redaction done with a black rectangle is not redacted. The underlying text is still in the file, selectable and searchable. Anything you need to redact should be removed from the document content, not just visually obscured.
• Metadata leaks the author’s identity. A PDF exported from Word carries your name, your company name, your computer’s username, timestamps, and the software version. Our PDF Compressor (and other PDF tools) strip metadata as part of processing, but for guaranteed removal, use a dedicated metadata scrubber before sharing.
• Password-protecting a PDF is weaker than AES encryption for sensitive content — PDF passwords can often be cracked. For true confidentiality, encrypt the PDF with a real encryption tool.

For images:

• EXIF metadata on photos from phones and cameras includes GPS coordinates. If you’re sharing a photo from a location you’d prefer not to disclose, strip EXIF first. Our Image Compressor re-encodes the image and drops most EXIF as part of processing.
• Screenshots can leak data from off-screen tabs (notification previews, clipboard content if you show a paste). Look at the whole screenshot before sharing; crop aggressively.

Part 7: browser hygiene

Your browser is where most privacy exposure happens. A few settings that materially improve your position:

• Use a privacy-respecting browser: Firefox (with strict tracking protection) or Brave by default. Safari is reasonable. Chrome/Edge, with their defaults, aren’t built for privacy.
• Block third-party cookies. Most modern browsers do this by default now.
• Limit extensions. Every extension with “access to all sites” can read any page you visit. Review your installed extensions; uninstall anything you don’t actively use. Browser extension supply-chain attacks are a real and recurring threat vector.
• Use container tabs (Firefox) or profiles to separate identities — work from personal, shopping from social.
• Clear cookies and site data periodically, or use a container per site.
• Private/Incognito mode doesn’t hide you from the website or your ISP. It just doesn’t save local history. Useful for borrowed computers, not for adversarial privacy.

Part 8: hashing and integrity

When you download a file from the internet — a software installer, a Linux ISO, a public dataset — the publisher often provides a hash (SHA-256 is the current default) so you can verify the file you downloaded matches the file they published.

The threat: a compromised mirror, a man-in-the-middle attacker, or a corrupted download could give you a different file. Hashing catches this.

sha256sum downloaded-file.iso

Compare the output to the hash published on the publisher’s website (which you reach over HTTPS). If they match, the file is authentic. If they don’t, delete it and try again.

Our Hash Generator computes SHA-256 and other hashes in the browser. The file never uploads — the hash is computed locally.

For verifying large files, a command-line tool is usually faster, but for a single file pasted into a form, the browser tool is fine.

Part 9: operational compartmentalization

The most powerful privacy practice is also the least-talked-about: don’t mix identities.

• Separate email addresses per domain of activity (one for work, one for shopping, one for social, one for financial). If one leaks, the others are unaffected.
• Separate payment methods — a card or virtual card per service. Privacy.com, Revolut, and some banks offer this. Trivially cancellable if a merchant gets breached.
• Separate browser profiles for different personas. Cookies and local storage don’t cross the boundary.
• Physical separation for the most sensitive work — a dedicated machine that never sees your casual browsing.

Most people won’t do all of this, and most don’t need to. But each step is independently useful: one leaked email doesn’t automatically expose the others, one compromised card doesn’t drain your accounts, one XSS attack on a social site doesn’t read your banking session.

Part 10: the everyday privacy checklist

For daily work, the short list:

• Password manager installed, actively used for every new account.
• 2FA enabled on email, banking, work accounts (authenticator app, not SMS).
• Browser has tracking protection on, extensions reviewed.
• Verification habit: check DevTools Network tab before uploading anything sensitive to a web tool.
• Second-channel rule: share encrypted files and passphrases through different channels.
• Metadata check: know what metadata your PDFs and images carry before sharing them externally.
• Quarterly review: go through active accounts, close ones you don’t use, rotate passwords on ones that failed modernization.

Closing: what privacy is and isn’t

Privacy isn’t secrecy. It’s control over who has what information about you, under what circumstances.

A privacy practice doesn’t have to be airtight to be useful. The realistic goal is:

• Fewer incidental exposures (a credit card leaked in a breach of a service you forgot about is worse than one you actively use).
• Less trackable aggregation (advertising profiles get thinner as you separate identities).
• Faster recovery when something goes wrong (a leak of one compartment doesn’t cascade to the others).

The tools linked throughout this guide — password generation , encryption , hashing , PDF compression , image processing — all run in the browser and don’t transmit your input anywhere. That’s not a marketing claim; it’s a property you can verify with DevTools.

The verifiability is what makes the difference. Most of online privacy isn’t about exotic tools or paranoid habits. It’s about the quiet practice of knowing what each tool actually does, choosing tools whose behavior you can check, and carrying those habits into the default way you work.

That’s the full picture. For specific topics, the cluster articles go deeper.