DEV Community: Sanjoy Karmakar

What is data classification, and why should you do it before you share a file?

Sanjoy Karmakar — Thu, 20 Aug 2026 11:17:29 +0000

Before you send a file, there's a question worth asking that most people skip: how sensitive is this, actually? Data classification is the practice of answering that question systematically — sorting a document into a sensitivity tier (typically Public, Internal, Confidential, or Restricted) so the handling matches the risk. A price list and a spreadsheet of customer card numbers shouldn't travel the same way, and classification is what tells you which is which before you hit send.

Frameworks like ISO/IEC 27001 (Annex A, information classification) and NIST's guidance on categorizing information sensitivity both build on this same idea: not all data deserves the same protection, so label it first and let the label drive the controls — encrypt this, restrict access to that, delete the other thing on a schedule.

What actually gets checked

Classifying a document by hand means reading it and judging what's inside — slow, and easy to miss something in a long file. A faster starting point is pattern matching: scan the text for the kinds of data that always raise the sensitivity level if present, regardless of context.

FileX's Data Classification Tagger does exactly this, entirely in your browser. It reuses the same detector set as the Anonymize tool — emails, phone numbers, dates of birth, IP addresses, and financial or government-ID identifiers — but instead of redacting what it finds, it counts and categorizes it to suggest a level:

Level	Triggered by
Restricted	A financial account or government-ID pattern: card numbers, IBAN, SSN, PAN, Aadhaar
Confidential	Personal contact information: email, phone, date of birth, IP address
Internal	Something else the detectors flagged (e.g. a bare URL), but nothing in the two tiers above
Public	No built-in pattern matched anything

The financial and government-ID identifiers aren't matched by shape alone. Card numbers are checked with a Luhn checksum, Aadhaar numbers with a Verhoeff checksum, and IBANs with the mod-97 check the IBAN standard itself defines — the same validation math banks and payment systems use to reject a mistyped number. That cuts down on a plain 16-digit string in a log file getting flagged as a card just because it happens to be the right length.

What it won't catch

This is pattern matching, not comprehension. It can't tell that a paragraph describes an unannounced acquisition, that a spreadsheet of employee names is sensitive even with no email or phone number attached, or that a photo shows something confidential in the background. Nothing that isn't a recognizable, checksummable pattern will trip a detector — and a tool that only looks for pattern matches can't have an opinion about context, tone, or intent.

That's why FileX describes the result as a suggested classification, not a certified one. It's a fast triage pass for a document you're about to send: if it comes back Restricted, you know to stop and think before it goes anywhere. If it comes back Public, that's a reasonable starting signal, not a legal guarantee — you still know your own document better than a regex does, and the tool's report says so explicitly.

From classification to action

A level only matters if it changes what you do next. A practical mapping:

Restricted — encrypt before sending. FileX's Encrypt tool locks any file behind a password with AES-256-GCM before it leaves your device; think about whether the recipient needs the raw identifiers at all.
Confidential — same instinct, lighter touch: encryption in transit, and consider whether personal details need to be there before sharing more broadly.
Internal — fine for internal channels, not for a public link or an open bucket.
Public — nothing here should surprise you if it leaked, but it's worth having checked rather than assumed.

If a file needs to go out with names, card numbers, or contact details stripped rather than just protected, that's a different job: the Anonymize tool redacts, masks, or pseudonymizes the same categories of data the classifier flags, so you can hand over a version that no longer carries the sensitive fields at all.

Try it before you send

Classification is a five-second check that catches the fifteen-minute-later "wait, did that file have customer data in it?" moment. Drop a document into the Data Classification Tagger — it reads the file locally, never uploads it, and tells you in seconds what it found and what tier it suggests.

How to build a data retention schedule (without inventing the periods yourself)

Sanjoy Karmakar — Thu, 20 Aug 2026 11:17:27 +0000

Most "data retention policy" documents fail for the same reason: someone typed in a period that sounded reasonable — "keep for 7 years," "delete after 90 days" — without it actually coming from anywhere. A retention schedule is only as good as the periods in it, and no software can tell you what those periods should be. What software can do is take the periods you already know and turn them into something concrete: a document, and a set of dates you'll actually see again.

Start with the one thing a tool can't give you: the periods

A data retention schedule needs three things per category of data: how long to keep it, what starts the clock, and why. The "why" — the legal or business basis — is what makes the period defensible instead of arbitrary. Tax records might follow a statute of limitations. Support tickets might follow an internal policy. Marketing data you collected with consent might follow whatever you told people in your consent notice.

None of that comes from a calculator. It comes from your legal or compliance advisor, the specific law that applies to your jurisdiction and industry, or a documented internal decision. If you don't have those periods yet, get them before you build the schedule — a schedule full of guessed numbers is worse than no schedule, because it looks authoritative.

What a retention schedule actually needs to record

Once you have the periods, each line in the schedule needs five things:

Data category — specific enough to be useful ("customer support tickets," not "data")
Retention period — a duration, like 3 years or 90 days
Trigger — the event the clock starts from: date collected, last activity, contract or relationship end, account closure, or something else you specify
Start date — the day that trigger actually happened, if it already has
Basis — the law, contract clause, or internal policy that justifies the period

That structure matters because of a distinction that is easy to get backwards. The question isn't which trigger a row uses — it's whether that trigger has already happened. A contract that ended last June is a known date, just as much as data collected on a known day, and both give you a review date you can compute right now. What you genuinely cannot compute is a trigger still in the future: a contract that hasn't ended, an account still open. Nobody knows those dates yet, because they depend on when the event actually happens. A schedule that pretends otherwise is fabricating a date it can't back up.

FileX's Retention Policy Calculator is built around that distinction directly, and it's worth being precise about what the tool does and doesn't do: it holds no retention periods, no legal defaults, and no jurisdiction-specific rules of its own. Every period, trigger, start date, and basis on the schedule is something you typed in. The tool's job is arithmetic and assembly — give any row a start date and it works out the review/delete date from your period, then formats the whole set of categories into a readable document. Leave the start date blank on a row whose trigger hasn't happened yet and it records the rule without pretending to know the date, and says so. It's also explicit about the difference between a date you supplied and one it assumed: a row marked "date collected" with no start date is read as collected today, and its date is labelled an example rather than presented as fact.

Turning the schedule into reminders you'll actually see

A retention schedule that lives in a document nobody reopens doesn't get enforced — it gets forgotten until an audit or a breach notification forces someone to go looking. The Retention Policy Calculator addresses that with a downloadable .ics calendar file: one reminder event per category, but only for rows where a review date could actually be calculated (a start date plus a valid period). Import it into whatever calendar you already use, and the review date shows up as a real appointment with a one-day-ahead alarm, not a line in a PDF you'll have to remember to check.

Categories whose trigger hasn't happened yet still appear in the schedule text — they're just not on the calendar, because there's no date yet to put there. When that event does happen (the contract ends, the account closes), that's your cue to come back, fill in the start date, and let the tool calculate the real review date from the rule you already recorded.

Where retention fits with what you've already told people

If you collect personal data from users, your retention period isn't a private decision — it's something you likely already disclosed. FileX's Consent Notice Generator includes a retention field in the notice it produces, precisely because "how long do you keep this" is a question a consent notice is expected to answer. Keeping the two in sync matters: a retention schedule that keeps customer data for 5 years while your public notice says 2 years is a discrepancy someone will eventually notice, and it undermines both documents.

The practical order is: decide the periods with your legal or compliance advisor first, state them consistently in your consent notice, then build the schedule from the same numbers. A tool can keep those two documents structurally aligned; it can't make the underlying decision for you.

The honest limits, stated plainly

A generated retention schedule is a formatting and date-arithmetic aid, not a compliance certification. It won't tell you that a period is legally correct, and it won't catch a period that's wrong for your jurisdiction. What it will do is turn periods you already know into a document with correctly computed dates, and turn every row whose trigger has already happened into a calendar reminder you're actually likely to see. That's a real, bounded piece of the work — not the legal judgment part, which stays yours.

Try the Retention Policy Calculator with your own categories and periods — nothing is uploaded, the schedule and the calendar file are both built entirely in your browser.

What makes a file-handling report "audit-ready"?

Sanjoy Karmakar — Tue, 11 Aug 2026 14:49:22 +0000

"We anonymized the file, then encrypted it" is a sentence. Written in an email or a shared doc, it's a claim a reviewer either trusts or doesn't — there's nothing stopping someone from editing it after the fact, or writing it before the work was ever done. Calling that record "audit-ready" doesn't change what it is.

An audit-ready report, as FileX builds it, is different in one specific, checkable way: it's tamper-evident. Understanding exactly what that does and doesn't prove is the difference between using it well and overselling it.

What the report actually is: an attestation, not a verification

FileX's Audit-Ready Report tool lets you record what was done to a file — classified, anonymized, metadata-scrubbed, encrypted, password-protected, watermarked, securely erased, or another action you specify — along with when it happened and any notes. It's important to be precise about what this is: it's an attestation the operator builds, not an independent audit. FileX doesn't watch you do the work and verify each action actually happened. It records what you entered. The report's disclaimer says this directly: it "attests to actions the operator recorded for this file... it is not an independent audit and not a compliance certification — it is only as accurate as what was entered."

That's not a limitation to hide — it's the honest boundary of what a client-side tool can promise. FileX never sees your infrastructure, your ticketing system, or your actual workflow. It can't independently confirm a file was really encrypted somewhere else. What it can do is turn your attestation into something that can't be silently edited later.

Where the actual value is: the integrity hash, and the optional signature

The report does one more thing on top of your attestation: at generation time, FileX scans supported text files (plain text, and text extracted from PDF and Word documents, entirely in your browser) using the same detectors as the Data Classification tool — patterns for emails, phone numbers, card numbers, and other personal or financial data — and attaches a suggested sensitivity level to the record.

Then the whole record — your recorded actions, the file's SHA-256, the classification scan, your notes — gets hashed with SHA-256 into an integrity hash. Recompute that hash later over the same data and compare it to the one in the report: if they match, nothing has been altered since the report was generated. That check needs no key, no server, and no trust in FileX itself — anyone can redo the arithmetic.

Signing is a separate, optional layer on top. You can sign the report's integrity hash with your FileX ID using ML-DSA-65, the same NIST-standardized (FIPS 204) post-quantum signature algorithm FileX uses for its erasure certificates — a fixed context string keeps the two signature types from being interchangeable. An unsigned report is still fully tamper-evident — the hash check works regardless. Signing adds attribution: proof of who generated the report, tied to a specific FileX ID, verifiable independent of FileX's own systems.

Reading a report

Each report bundles a few things: a plain-text summary, the machine-readable JSON record, and a formatted HTML or PDF version with the same data embedded so it stays independently verifiable — open the HTML report and the underlying JSON is right there to re-check. The report lists your file's name, size, and SHA-256; your recorded actions; the classification scan (if one ran); your notes; and finally the integrity hash and signature status.

That structure is deliberate. It separates "what the operator says happened" (the actions and notes — trust these the same way you'd trust any human-entered record) from "what can be mathematically checked" (the hash, and the signature if present). A reviewer who understands that split gets real information out of the report instead of false confidence.

When this is worth using

If you're the only one who'll ever see the record, a plain note is fine. An audit-ready report earns its place when the record needs to survive contact with someone else — a client, an auditor, a compliance reviewer, or your future self trying to reconstruct what happened to a file six months later. The tamper-evidence means the report can't be quietly edited after review without the hash breaking; the optional signature means it can be traced to a specific identity years later, even against a future with quantum computers capable of breaking today's non-post-quantum signatures.

Try the Audit-Ready Report Generator on a file — nothing is uploaded, the classification scan and the report itself run entirely in your browser.

What is a signed erasure certificate, and why does it matter?

Sanjoy Karmakar — Tue, 11 Aug 2026 14:49:20 +0000

A spreadsheet that says "wiped: yes" proves nothing. Anyone with edit access can change "yes" after the fact, or write it before the wipe ever ran. If a compliance reviewer, a client, or an auditor has to take that row on faith, it isn't evidence — it's a claim.

A signed erasure certificate is different: it's built so that any change to it is detectable, and — optionally — so that the party who issued it can be cryptographically tied to it. Here's what those two guarantees actually rest on, and how to check one yourself.

Two separate claims, two separate mechanisms

A trustworthy erasure record has to answer two different questions:

Has this record been altered since it was issued? (tamper-evidence)
Who issued it? (attribution)

FileX's certificate format answers the first one always, and the second one only if the person generating it chooses to sign. They're independent layers, and conflating them is the most common way "signed certificate" claims get oversold.

Layer one: the integrity hash (always present, no key required)

Every certificate — from the in-browser Eraser tool or the downloadable FileX Eraser Tool CLI — is a JSON record: an operation ID, a timestamp, the erasure method used, the list of items and their status, and a plain-language disclaimer about what the method does and doesn't guarantee.

To make that record tamper-evident, FileX serializes it with a canonical form — object keys sorted recursively, then compact JSON — and hashes that with SHA-256. The result is stored on the record itself as integritySha256. Anyone can recompute the hash over the same canonical form and compare it to what's stored: if a single byte of the operation details changed after the fact, the hash won't match.

This costs nothing to check — no key, no trust in FileX, no network call. It's the same reason a checksum can prove a download wasn't corrupted; here it proves an erasure record wasn't edited after it was generated. (If checksums are new to you, see how SHA-256 verification works.)

What the hash alone doesn't prove is who generated the record. Anyone can run the eraser and get a validly-hashed certificate — the hash says "unaltered," not "issued by a specific person or organization."

Layer two: the signature (optional, proves who)

For that, FileX offers an optional digital signature using ML-DSA-65, a post-quantum signature algorithm standardized as FIPS 204. When you sign a certificate, FileX signs the certificate's integritySha256 digest with your FileX ID — the same identity used elsewhere in FileX for quantum-safe encryption — and attaches the signature alongside a kid (a short fingerprint of your FileX ID's public keys) and the public key needed to verify it.

Two details matter here:

The signature covers the hash, which already commits to the entire canonical record — so signing the hash is equivalent to signing the whole certificate.
The signing context string is domain-separated (FileX-cert-sig-v1) from FileX's other ML-DSA uses, like signed audit reports or signed FXQ files. A signature made for one purpose can't be replayed as proof for another.

Because signing is tied to your FileX ID's kid, a recipient who already recognizes that fingerprint — say, from a past encrypted exchange — has a second, independent reason to trust the signer, not just the hash.

An unsigned certificate is still fully tamper-evident; it's just not attributable to anyone in particular. Whether you need the signature depends on whether the person receiving the certificate needs to know it was you specifically who ran the wipe, versus just that the record wasn't altered.

Verifying one yourself

You don't need FileX's servers to check a certificate — there aren't any in this flow, and there's nothing to trust but math. The Verify Certificate tool takes a certificate JSON file, recomputes the canonical hash locally, and reports:

whether the hash matches (tamper-evidence intact or broken)
if a signature is present, whether it verifies against the embedded public key, and the signer's kid

Recomputing happens entirely in your browser. Nothing about the certificate you're checking gets uploaded anywhere.

Where the guarantee stops

A signed certificate proves the record wasn't altered, and optionally who signed it. It does not upgrade what the underlying erasure method actually achieved. The certificate's own disclaimer says this plainly: the in-browser Eraser performs a best-effort logical wipe — overwrite, then delete — which is NIST SP 800-88 "Clear." On SSD and flash media, wear-leveling can leave the original data in cells the software overwrite never reached, so this isn't a forensic destruction guarantee. For NIST 800-88 "Purge" — cryptographic erase or a drive's native secure-erase command — you need the downloadable FileX Eraser Tool, which can also produce a certificate in the exact same format.

That "exact same format" detail is deliberate: the browser tool and the desktop CLI hash their certificates identically, byte for byte, so a certificate from either one verifies the same way and neither format needs its own tooling.

The takeaway

A deletion log is a claim. A hashed record is tamper-evident. A signed record is tamper-evident and attributable. Know which one you're holding, and don't assume a "certificate" implies more than its own disclaimer states.

Run an erasure with the in-browser Eraser tool, optionally sign it with your FileX ID, and check the result with the Verify Certificate tool — all locally, nothing uploaded.

What is post-quantum encryption, and does your data need it yet?

Sanjoy Karmakar — Tue, 11 Aug 2026 12:53:29 +0000

"Post-quantum" gets used as a catch-all scare word, which makes it easy to assume every kind of encryption needs replacing before quantum computers arrive. That's not quite right. Post-quantum file encryption is really about one specific weak point — how two parties agree on a secret key in the first place — not about the cipher that scrambles your file bytes. Here's the actual distinction, why it matters today rather than someday, and how FileX applies it.

The attack that matters today: harvest now, decrypt later

No quantum computer today can break modern encryption. The risk isn't that your files are readable now — it's that an adversary can copy encrypted data today and simply hold onto it, betting that a future quantum computer will be able to unlock it. CISA, the NSA, and NIST jointly warned about exactly this in their Quantum-Readiness fact sheet: adversaries are already collecting encrypted data with the intent to decrypt it once a sufficiently powerful quantum computer exists. This is why "does your data need post-quantum protection yet?" is the wrong question if the data needs to stay confidential for years. The attack against it may already be underway; only the decryption is scheduled for later.

AES-256 doesn't need a fix

Start with what's not the problem. FileX encrypts your file bytes with AES-256-GCM — a symmetric cipher, meaning the same key both locks and unlocks the data. The best-known quantum attack against a symmetric cipher is Grover's algorithm, which speeds up brute-force key search quadratically, not exponentially. Against a 256-bit AES key, that leaves roughly 128 bits of effective security against a quantum attacker — still astronomically out of reach. AES-256 does not need a post-quantum replacement. If you see a product claiming to have "quantum-proofed" its symmetric cipher, be skeptical of what problem it's actually solving.

The real threat: asymmetric key exchange

The threat is to asymmetric cryptography — the algorithms that let two parties who've never met establish a shared secret over an open channel, like X25519 (Elliptic Curve Diffie-Hellman, RFC 7748) or RSA. Their security rests on math problems — the elliptic-curve discrete-log problem, integer factorization — that a sufficiently large quantum computer running Shor's algorithm could solve outright, not just weaken. That's a full break, not a strength cut in half. Any file encrypted today to a recipient using only classical key exchange is exactly the kind of data a "harvest now, decrypt later" adversary would want copied and shelved.

Hybrid encryption: secure if either half holds

The practical defense NIST settled on isn't to abandon classical key exchange — it's to combine it with a quantum-resistant algorithm, so the combined result stays secure as long as at least one of the two remains unbroken. In August 2024 NIST finalized the first Federal Information Processing Standards for this: FIPS 203 standardizes ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber) for key exchange, and FIPS 204 standardizes ML-DSA (derived from CRYSTALS-Dilithium) for digital signatures. Both are believed secure even against an adversary holding a large-scale quantum computer.

How FileX applies this: the FileX ID

When you create a FileX ID, FileX generates a hybrid keypair entirely in your browser: an X25519 keypair alongside an ML-KEM-768 keypair, plus an ML-DSA-65 keypair for signing. The private keys never leave your device. When someone encrypts a file to your FileX ID, FileX's hybrid.js module runs both key agreements and combines the results rather than picking one:

ss_ec = X25519(ephemeral_priv, your_x25519_pub)
ss_pq = ML-KEM-768.Encapsulate(your_mlkem_pub)
KEK   = HKDF-SHA-256(ss_ec || ss_pq, info = transcript-binding context)

The file's actual encryption key is then wrapped under that combined KEK with AES-256-GCM. Because the key-encapsulation key is derived from both shared secrets concatenated together, an attacker has to break both X25519 and ML-KEM-768 to recover it — breaking only one gets them nothing. That's the concrete meaning of "quantum-safe" here: it isn't that AES got upgraded, it's that the key delivered to AES can no longer be exposed by breaking just the classical half.

Signatures follow the same logic in one layer, not two: when you tick "sign" while encrypting, FileX signs with ML-DSA-65 so the recipient can verify the file came from your FileX ID and wasn't altered — the same post-quantum signature standard also signs FileX's erasure certificates, independent of file encryption.

Does your data need this yet?

If a file only needs to stay confidential for a few days or weeks, the classical-only risk window is small. But for anything with a long confidentiality shelf life — legal records, medical data, source code, anything embarrassing or regulated for years to come — "harvest now, decrypt later" means the exposure window opened the moment it was encrypted with classical-only key exchange, not the moment a quantum computer arrives. Password-based encryption (FileX's FXQ1 container, derived with Argon2id) is a separate case: it isn't vulnerable to Shor's algorithm at all, since there's no asymmetric key exchange to attack — a strong, unique password remains the deciding factor there.

The recipient-encryption case is where the asymmetric key-exchange question actually applies, and it's where hybrid key exchange earns its keep.

Takeaway

Post-quantum protection is about asymmetric key exchange, not about swapping out AES — AES-256 already resists quantum attacks with a comfortable margin.
The real-world risk today is "harvest now, decrypt later": encrypted data copied now to be decrypted once quantum computers are strong enough.
FileX's FileX ID combines classical X25519 with post-quantum ML-KEM-768 via HKDF, so security holds even if one algorithm is later broken.
Encrypt a file to a FileX ID to try it — nothing is uploaded, and only the recipient's private key, never generated or seen by any server, can open it.

Is it safe to send files with a link? What the server actually sees

Sanjoy Karmakar — Fri, 31 Jul 2026 08:46:50 +0000

You drop a file into a "share a link" tool, get a URL back, and send it along. Is it safe to send files with a link? It depends entirely on one question most people never ask: what does the server hosting that link actually have access to? For most link-based transfer tools, the honest answer is "your file, in plaintext, sitting on someone else's storage." Here's what that risk looks like in practice, and what changes when the file is encrypted before it ever leaves your device.

What a typical file-link service actually holds

A conventional "send a file, get a link" service works by uploading your file as-is. The server receives the plaintext bytes, stores them, and hands out a link that lets anyone with the URL fetch them back. That means the provider — and anyone who compromises the provider, or is legally compelled to hand over data, or simply mis-configures a storage bucket — has the same access to your file that you do. The link itself is usually just an opaque ID; it doesn't protect the contents, because nothing about the file was ever hidden from the server that's serving it.

This is the same category of risk covered in is it safe to use online PDF tools: once a file is uploaded to a server you don't control, its confidentiality rests entirely on that server's security practices, retention policy, and legal exposure — not on anything you did.

The one FileX tool that isn't fully local — and why

Every other tool in FileX runs 100% in your browser: nothing is ever uploaded, full stop. FileX Send is the deliberate exception, because a link that works later — potentially from a different device — has to hold the file somewhere in between. Rather than pretend otherwise, FileX documents exactly what that costs you on a dedicated Send threat model page.

The design minimizes what the server ever gets to see:

Your browser generates a random encryption key locally.
The file is encrypted with that key — AES-256-GCM, the same authenticated cipher used everywhere else in FileX — before a single byte is uploaded.
Only the ciphertext goes to the server.
The key never travels with the upload request. It's appended to the share link after a #, a URL fragment — a client-side-only part of the URL that browsers never send in an HTTP request. So the server storing your ciphertext never receives the key that unlocks it.

FileX Send's Team tier adds a second layer: an optional password. When set, the actual file key isn't the link key alone — it's derived by combining the link key with the password through HKDF, a standard key-derivation function (RFC 5869), the same construction FileX's hybrid encryption already relies on elsewhere. That means possessing the link alone isn't enough to decrypt a Team file — the password has to reach the recipient through a separate channel, the same "don't send the key with the message" principle covered in how to send a password securely.

What the server can see — and what it can't

Being upfront about this is the point. FileX Send's server side can see:

The ciphertext bytes and their size.
A routing ID — an opaque key with no information about the file itself.
The link's expiry time and how many times it's been downloaded.
Which pricing tier the sender is on, but only if a license key was attached to the upload.

It can never see: the encryption key, the Team password, the plaintext file contents, or the original filename — which also travels only in the link fragment, never in the request.

Links don't sit around indefinitely, either, and the limits are enforced server-side rather than just suggested by the UI. They vary by tier and do change as the product evolves, so check the Send tool page for current numbers rather than trusting an old post. Free-tier links expire fastest and self-destruct after a single download; paid tiers get longer-lived links with higher size caps and unlimited downloads until expiry; Team links add the password requirement above. Once a link expires or hits its download limit, both the encrypted object and its metadata are deleted.

So — is it safe?

"Safe" depends on what you're protecting against. Encrypting client-side before upload closes off the biggest risk in ordinary link-sharing services: a server operator, or anyone who breaches that server, reading your file. With FileX Send, they'd get ciphertext and nothing to decrypt it with. What client-side encryption doesn't change is availability — the encrypted blob still has to exist somewhere until the recipient downloads it, and its size and rough timing are visible to whoever hosts it. If even that tradeoff isn't one you're willing to make — ciphertext held temporarily, in exchange for a link that works without both people online at once — keeping the file off any server entirely is still an option: encrypt a file to a FileX ID so only one recipient's private key can ever open it, and hand it over however you like.

For most people sharing a document or photo with someone who isn't ready to receive it in the next five minutes, a link where the host only ever holds ciphertext is a meaningfully safer proposition than one where it holds your file in the clear.

Ready to try it? Send a file securely — your file is encrypted before it leaves your browser, and you can read exactly what the server does and doesn't see on the threat model page.

What is a SHA-256 checksum and how do you verify a download?

Sanjoy Karmakar — Fri, 31 Jul 2026 08:31:52 +0000

A software vendor posts a download link next to a string like a94a8fe5ccb19ba61c4c0873d391e987982fbbd3. That string is a checksum — and if you've ever wondered whether you're supposed to do anything with it, the answer is yes. Here's what a SHA-256 checksum actually is, when checking one matters, and how to verify a download's checksum in your browser.

What a checksum actually is

A checksum (also called a hash or digest) is the output of a cryptographic hash function run over a file's bytes. SHA-256 — part of the SHA-2 family, published by NIST — always produces the same 256-bit (64 hex character) output for the same input, and a single changed byte anywhere in the file produces a completely different output. That's what makes it useful for verification: it's not a summary of the file, it's a fingerprint of every byte in it.

Two properties matter here:

Deterministic. The same file, hashed twice, always produces the same digest — on any machine, in any browser, with any implementation, because the algorithm is a fixed public specification, not something proprietary to one tool.
Collision-resistant. Finding two different files that produce the same SHA-256 digest is, as far as anyone has publicly demonstrated, computationally infeasible. So a matching digest is strong evidence the bytes are identical, not just similar.

A checksum doesn't tell you a file is safe — malware can ship with a perfectly valid checksum for its own bytes. What it tells you is that the file you have is the exact file the checksum was computed from: nothing added, removed, or flipped in transit.

When to actually check one

Most downloads, most of the time, you don't bother. Checking a checksum earns its keep in a few specific situations:

Installers and firmware. A corrupted download of an OS installer or a firmware image can brick a device or fail installation halfway through in a way that's hard to diagnose. Confirming the checksum before you run it catches that up front.
Large file transfers. The bigger the file, the more likely a partial download or flaky connection leaves you with a truncated or corrupted copy. A checksum mismatch tells you immediately, instead of discovering it when the file won't open.
Verifying nothing changed. If you need to prove a document or dataset is identical to a version you fingerprinted earlier — for an audit trail, a compliance record, or just your own peace of mind — comparing checksums over time does that without needing to diff the whole file by hand.
Confirming a publisher's signature. Many open-source projects publish a SHA256SUMS file alongside their releases specifically so downloaders can verify integrity independently of the download mirror they used.

If the checksum you compute doesn't match the one the publisher listed, don't run the file. A mismatch means the bytes differ from what was published — from ordinary network corruption at best, to a tampered file at worst. Either way, re-download from the source rather than trusting it.

How to verify a checksum in your browser

FileX's file integrity tool computes cryptographic digests entirely client-side, using the browser's built-in Web Crypto API (crypto.subtle.digest) — the file is read locally and never uploaded anywhere:

Open the integrity tool and drop in the file you downloaded.
Pick an algorithm. SHA-256 is the most common for public checksums; SHA-384 and SHA-512 are also available for cases that call for a longer digest, and SHA-1 is offered only for comparing against older, legacy-published checksums — it's cryptographically broken for anything security-sensitive and shouldn't be trusted to detect deliberate tampering.
Paste the checksum the publisher listed into the "compare against" field, and hit compute. FileX hashes the file locally and tells you outright whether it matches — no eyeballing a 64-character hex string for a typo.

If you need to fingerprint several files at once — say, an entire release directory — the tool's Manifest mode hashes every file you drop in and produces a downloadable SHA256SUMS-style checksum list in one pass, matching the format most open-source projects already publish.

Checksum vs. HMAC: when you need a shared key

A plain checksum verifies integrity — that the bytes weren't altered — but anyone can compute a SHA-256 digest of a file, including whoever might have tampered with it and then republished a matching checksum alongside it. If you need to prove the digest itself couldn't have been forged by someone without a shared secret, that's what HMAC (keyed-hash message authentication) is for.

FileX's integrity tool includes an HMAC mode: you supply a secret key alongside the file, and it computes a keyed digest via crypto.subtle.sign('HMAC', ...). Anyone verifying the HMAC needs the same key — so unlike a plain checksum, a valid HMAC also proves the digest came from someone who holds that key, not just from someone recomputing a hash after the fact. This is the same authenticated pattern that underlies how AES-256-GCM protects your files: encryption alone tells you a file is confidential, but an authentication tag (or here, an HMAC) is what tells you it hasn't been altered by someone without the key.

The short version

A SHA-256 checksum is a deterministic fingerprint of a file's exact bytes — matching digests mean identical files, a mismatch means something changed.
Check checksums for installers, firmware, large transfers, and anything you need to later prove wasn't altered.
Use HMAC instead of a plain checksum when you need to prove the digest came from someone holding a shared key, not just anyone who recomputed a hash.
FileX computes SHA-1/256/384/512 digests and HMACs entirely in your browser via the Web Crypto API — the file is read locally and never uploaded.

Have a download to verify? Compute its checksum now — nothing leaves your browser, and the live monitor on the page shows exactly zero bytes uploaded.

How to send a password securely (stop pasting it in chat)

Sanjoy Karmakar — Fri, 24 Jul 2026 10:10:00 +0000

You just reset a shared account's password, or you're handing a Wi-Fi key to a houseguest, or a client needs a login for a portal. The easy move is to paste it straight into Slack, WhatsApp, or an email. The problem: that message doesn't disappear. It sits in your chat history, the recipient's chat history, both parties' cloud backups, and any device either of you is signed into, indefinitely — in plain text, readable by anyone who later gets into any one of those places.

Here's how to send a password securely instead: encrypt it before it touches a chat or email thread, and split it from its own decryption channel.

Why pasting it in chat is the weak point

A password typed into a messaging app isn't "sent and gone." It's stored, usually more than once:

Chat history, searchable by anyone who later gains access to either account.
Cloud backups of that chat, often kept far longer than the conversation itself.
Notification previews, which can flash the password on a lock screen.
Server-side logs, if the tool routes messages through a provider you don't control.

None of that requires anyone to "hack" anything — it just requires someone who already has access to one of those places, at any point in the future. The fix isn't a better messaging app. It's not leaving a readable secret in any of those places to begin with.

Encrypt the secret, then send the encrypted version

FileX's Secret Note tool turns your message into ciphertext before it ever leaves your device:

Open the Secret Note tool and type or paste the password (or address, or message) into it.
Set a password to protect it. This encrypts the text locally with AES-256-GCM, the same authenticated cipher FileX uses for file encryption — the key is derived from your password with PBKDF2-HMAC-SHA256 and a random salt, run entirely in your browser.
Copy the output. It's a plain-text block — ----- BEGIN FILEX NOTE ----- … ----- END FILEX NOTE ----- — that pastes cleanly into any chat app, email, or ticket, because it is just text, base64-encoded.
Send that block over whatever channel you'd already planned to use.

Nothing about this step touches a server. The note is encrypted on your device and never uploaded — you can check the "nothing uploaded" monitor on the page while you do it.

To read it back, the recipient pastes the block into the same tool's Decrypt mode and enters the password. If the password is wrong, or the block was altered in transit, decryption fails outright rather than returning garbled text — that's the authentication tag in AES-GCM doing its job, the same mechanism covered in how AES-256-GCM keeps your files safe.

The part that actually matters: use a second channel

Encrypting the note only helps if the password protecting it doesn't travel the same path as the note itself. If you encrypt a secret and then send both the encrypted block and its password down the same Slack thread, you've just moved the plaintext-in-chat problem one message later — anyone who can read that thread can decrypt the note too.

Split it instead:

Send the encrypted note by chat, email, or a shared doc.
Deliver the password by a different channel — a phone call, an SMS, in person, or a separate app entirely.

An attacker (or a future account compromise) now has to control two channels, not one, to reconstruct the secret. That's the entire value of encrypting it in the first place — don't undo it by keeping the password on the same thread.

Don't reuse a weak password for the wrapper either

The password protecting your note is doing real cryptographic work — it's the input to the key derivation, and a short or guessable one narrows the search space an attacker has to try. Don't reuse an existing account password as the wrapper; generate a fresh one for this purpose with FileX's password generator, which draws randomness from your browser's CSPRNG (crypto.getRandomValues, never Math.random) rather than anything predictable:

A random password (8–64 characters, with toggles for lowercase, uppercase, digits, and symbols) — every character sampled with unbiased rejection sampling, one character guaranteed from each class you select.
A diceware-style passphrase (3–10 words from a 7,776-word list, optionally capitalized or suffixed with a number) — easier to read aloud over that phone call than a random string, and just as calculable: each word contributes about 12.9 bits of entropy, so a 5-word passphrase lands around 65 bits before any added number.

Either way, the generator shows you the resulting entropy so you're not guessing at strength.

The short version

Don't paste a password directly into chat, email, or a ticket — it lives on in history and backups long after you've forgotten it.
Encrypt it first with the Secret Note tool: AES-256-GCM, PBKDF2-derived key, nothing uploaded.
Send the encrypted block and the password over separate channels — that split is what actually protects the secret.
Generate the wrapper password with a CSPRNG-based password generator rather than reusing one you already know.

Ready to send one? Encrypt your secret note now — it runs entirely in your browser, and the live monitor on the page shows exactly zero bytes leaving it.

How to redact a PDF properly (black boxes aren't enough)

Sanjoy Karmakar — Fri, 24 Jul 2026 10:09:59 +0000

If you've ever learned how to redact a PDF by drawing a black rectangle over the sensitive part, you should know: in most tools, that rectangle is decoration. The text underneath is still there, and it usually takes nothing more than a copy-paste or a drag of the shape to get it back. Real redaction means the underlying content is gone — not covered.

Why a black box usually isn't redaction

A PDF page isn't a flat picture by default — it's a set of objects: text runs, positions, fonts, images, all still readable by software even when something visually sits on top of them. Drop a black rectangle over a paragraph in a word processor, export to PDF, and you've added one more object to the stack. The paragraph is still in the file underneath it.

That gap has caused real, public leaks. Redactions have been reversed by selecting and copying the "hidden" text, by deleting the covering shape in a PDF editor, or by extracting the underlying text layer with any PDF parser. None of that requires special tools — just the willingness to try.

What real redaction requires

Genuine redaction has one job: make sure the sensitive content cannot be recovered from the file you hand out, by any method. That means the original text and image data covered by a redaction has to be destroyed, not layered over. A tool that draws a shape and calls it done hasn't done the job — the safe assumption for anyone downstream is that a redaction is real only if the file's underlying structure no longer contains what it's hiding.

How FileX redacts a PDF

The Redact a PDF tool (part of the FileX PDF Editor, a Pro feature) handles this by rasterizing, not overlaying. When you mark an area for redaction and export the document, any page that has a redaction on it is rendered to a flattened image — the original text, fonts, and vector objects on that page are replaced entirely by that image, with your black boxes baked directly into the pixels. There's no text layer left to copy, no hidden object to peel away, and no shape you can nudge aside — because there's no shape at all in the output, just a picture. Pages you didn't redact keep their original, unmodified content, so you only lose text-selectability on the pages that actually needed it.

As with every FileX tool, this happens entirely in your browser — the document is never uploaded to redact it.

Redaction isn't metadata removal

These solve two different problems, and it's easy to fix one while forgetting the other:

	What it removes	What it leaves alone
Redaction	Visible content on the page (text, images)	Document properties (author, software, timestamps)
Metadata removal	Author, producer, creation/modification dates, title, keywords	The visible page content

A PDF you've redacted can still name you as the author in its document properties. If you're sending a document out and you want both — no visible sensitive content and no author fingerprint — run it through both tools: redact first, then clear the metadata. We cover the metadata side in more depth in the hidden metadata your photos and PDFs leak.

Before you send it

Don't rely on a black box drawn in a word processor or a basic PDF viewer. If the shape can be deleted or the text can be copy-pasted, it isn't redaction.
Cover the area completely. A redaction that clips the edge of a word can leave a legible fragment.
Check the metadata separately. Redacting content doesn't clear the author or producer fields — that's a separate step.
Confirm you can't select the "hidden" text in the exported file. If you can highlight it with your cursor, it wasn't redacted.

Redacting properly costs you one thing: the redacted page becomes an image, so its text is no longer selectable or searchable — that's the trade-off for the content actually being gone. For a document you're about to share outside your organization, it's the right trade to make. Try the PDF Editor's Redact mode — the file stays on your device the entire time, redaction included.

What is EXIF data, and how do you remove it from a photo?

Sanjoy Karmakar — Wed, 15 Jul 2026 08:56:08 +0000

Every photo your phone or camera takes carries an invisible passenger: EXIF data. It rides along inside the file, adds nothing to what you see on screen, and can quietly tell a stranger where you were standing when you took the picture. Here's what EXIF data actually is, what it can reveal, and how to strip it before you share a photo.

What is EXIF data, exactly?

EXIF stands for Exchangeable Image File Format — a standard, maintained by the Camera & Imaging Products Association (CIPA), for embedding a block of metadata inside a JPEG photo. When a digital camera or phone saves a JPEG, it writes a small binary block right after the start of the file (technically, an APP1 segment structured like a miniature TIFF file) containing tags about the shot: not the pixels, but facts about the pixels.

It's not a hack or a leak in the traditional sense — EXIF was designed to be there. The problem is that almost nobody ever looks at it before hitting send.

What's actually inside an EXIF block

A camera can write dozens of EXIF fields, but the ones that matter for privacy are a short list:

Field	What it reveals
`Make` / `Model`	The exact phone or camera model that took the photo
`Software`	The app or firmware version used to process it
`DateTime` / `DateTimeOriginal`	When the photo was taken and last saved, to the second
`Artist` / `Copyright`	A name, if the device or app was configured with one
`Orientation`	Which way to rotate the image for display
`ExposureTime` / `FocalLength`	Camera settings — not private, but confirms real gear was used
`GPSLatitude` / `GPSLongitude`	The exact location the photo was taken, often to within a few metres

That last one is the field that actually causes harm. GPS coordinates baked into a photo are precise enough to point at a front door, a workplace, or a child's school — from a single JPEG, with no other information needed.

The Orientation tag is worth a specific mention because it's the one EXIF field browsers already act on: the CSS image-orientation property's default value, from-image, tells the browser to auto-rotate a JPEG using this exact tag — proof that EXIF isn't some obscure forensic curiosity, it's live metadata your own browser reads today.

How to see what your photo is carrying

You don't have to take any of this on faith — you can look. FileX's Inspect tool reads a JPEG's EXIF block and lists every tag it finds, including a specific warning if GPS coordinates are present, before you decide to share anything. It's read-only: nothing is written back to the file, and because it runs entirely in your browser, the photo itself never leaves your device just to be checked.

How to remove EXIF data from a photo

Once you know what's there, removing it is one step: FileX's Scrub tool takes a JPG or PNG and re-encodes it as a fresh JPEG at 95% quality, using the browser's <canvas> element. That re-encode is the whole mechanism — a canvas only ever knows about pixels, so when it redraws your photo it has no way to carry the old EXIF block along. The output is visually identical, full resolution, same content — just without the metadata that came in.

Two things worth knowing about that process:

It always produces a JPEG, even if you dropped in a PNG. If your source was a PNG with embedded metadata, re-encoding still discards it.
Because it's a genuine re-encode at high quality (not a lossless strip), there's no meaningful visible quality loss, but it isn't a bit-for-bit copy of the original either.

Does resizing or cropping remove EXIF automatically?

Not necessarily — plenty of photo editors preserve the EXIF block when they resize or crop, because they write the new pixels back into the same container without touching the metadata section. The only way to be sure is to either check with a tool like Inspect, or use a tool that explicitly re-encodes through a metadata-blind path like canvas — which is exactly what removes it here.

A quick before-you-send checklist

Selling something online? Product photos taken at home routinely carry GPS. Scrub before you post the listing.
Sharing photos from an event or trip? Timestamps and device model are low-risk alone, but combined with GPS they build a fuller picture than most people intend to share.
Sending a photo to someone you don't fully trust? Inspect first — it takes seconds and costs nothing to know.

EXIF is only half the metadata story — PDFs and other documents carry their own hidden properties (author names, software fingerprints, timestamps), which works a little differently. The deeper look at hidden metadata covers both photos and documents side by side if you want the fuller picture.

Curious what your own photos are carrying? Drop one into the Inspect tool — it's free, read-only, and nothing is uploaded.

How to securely erase an SSD (and why overwriting isn't enough)

Sanjoy Karmakar — Fri, 10 Jul 2026 09:35:35 +0000

If you're about to sell, return, or recycle a laptop, the instinct is to delete your files, maybe run an overwrite tool, and call it done. On a spinning hard drive that instinct is basically correct. On a solid-state drive (SSD) — which is what's inside almost every laptop sold today — it isn't. You can securely erase an SSD, but not by overwriting files in place. Here's why, and what actually works.

Why file overwrites don't reliably erase an SSD

Overwriting a file writes new bytes over the old ones so the original content is physically replaced — that's real erasure, and it's exactly what an in-browser eraser tool does. The catch is what "in place" means on flash storage.

An SSD can't rewrite a single cell the way a magnetic platter can. To spread physical wear evenly and stay fast, SSD controllers use wear-leveling: when your OS "overwrites" a file, the controller frequently parks the new data in a different physical location and retires the old block instead of erasing it there. The filesystem reports success. The original bytes may still exist in a block the OS can no longer even address. We cover this mechanism — and the related myth that more overwrite passes helps — in more depth in does deleting a file actually erase it?

The upshot: a software overwrite on an SSD is a best-effort logical wipe. It defeats undelete and file-recovery tools, which is the level NIST calls "Clear." It cannot promise a lab with the right equipment won't recover a fragment from a retired block. For most everyday deletions, Clear is genuinely enough. For a drive that's about to leave your hands entirely, it usually isn't.

The reference standard: NIST SP 800-88

NIST Special Publication 800-88, "Guidelines for Media Sanitization," defines the escalating levels that matter here:

Level	What it does	Defeats
Clear	Overwrite user-addressable storage with new data	Standard undelete / recovery software
Purge	Techniques that resist laboratory recovery — cryptographic erase, or the drive's own firmware sanitize command	Forensic recovery
Destroy	Physical destruction of the media	Everything

A whole SSD you're decommissioning calls for Purge, not Clear. NIST 800-88 lists two practical ways to get there on flash media:

Cryptographic erase — if the drive (or a volume on it) was encrypted, destroying the encryption key instantly makes every block unreadable, no matter which physical location the controller actually wrote to. This is the fastest and most broadly applicable Purge method for SSDs, provided encryption was on from the start.
The drive's own sanitize / secure-erase command — issued directly to the controller (ATA Secure Erase for SATA drives, NVMe Sanitize for NVMe drives). The firmware erases the flash itself, which is the one layer that isn't fooled by wear-leveling, because it operates below it.

Both require access a web browser simply doesn't have — this is OS- and firmware-level work, not something JavaScript running in a tab can issue.

What that actually looks like

Concretely, reaching Purge on a real machine means one of:

Linux, LUKS-encrypted drive: destroy the volume key (cryptsetup luksErase) for an instant crypto-erase.
Linux, NVMe: issue an NVMe Sanitize block-erase (nvme sanitize) — the drive's firmware wipes itself.
Linux/any OS, SATA SSD: the drive's ATA Security Erase Unit command (often run via hdparm --security-erase).
macOS: disable FileVault and destroy the APFS volume key for a crypto-erase, or use the drive's native secure-erase utility.
Windows: turn off BitLocker and reformat to destroy the key, or run the drive vendor's secure-erase tool.

These are irreversible, whole-device operations — exactly the kind of thing that shouldn't run silently or by accident, and exactly why FileX draws a hard line around them.

Where FileX's two erasure tools fit

FileX ships two erasure tools, and each is honest about which level it reaches:

The in-browser Eraser overwrites and deletes the contents of a folder you choose, entirely in your browser via the File System Access API — nothing leaves your device. That's Clear: it reliably defeats recovery software, and it's the right tool for cleaning out sensitive files you're done with day to day. It is not, and doesn't claim to be, a whole-drive Purge tool — a browser tab can't touch drive firmware.

The downloadable FileX Eraser Tool (native, Windows/macOS/Linux, Pro-licensed) also supports crypto-erase and purge methods for whole devices. Deliberately, it does not fire the firmware sanitize command itself — that's a destructive, irreversible action on an entire disk, and an unsigned CLI shouldn't auto-execute it. Instead it detects your OS and prints the correct, vetted native command for your platform (nvme sanitize, hdparm --security-erase, cryptsetup luksErase, diskutil secureErase, or the BitLocker equivalent) so you run it deliberately, as an admin, against the right device. For file- and folder-level clear jobs it runs the erase itself and produces the same tamper-evident certificate as the web tool.

The practical takeaway

Deleting or even overwriting individual files on an SSD is Clear-level protection — good for day-to-day cleanup, not a guarantee for hardware leaving your control.
The reliable way to reach Purge on an SSD is cryptographic erase (destroy the key) or the drive's own ATA Secure Erase / NVMe Sanitize command — both need OS- or firmware-level access.
Turn on full-disk encryption from day one on any drive you might ever resell or return. It makes a future crypto-erase instant instead of impossible.
For files you want gone right now, not a whole drive, the in-browser Eraser overwrites and deletes them locally and hands you a certificate — nothing uploaded.

PBKDF2 vs Argon2 vs bcrypt — which key-derivation function and why

Sanjoy Karmakar — Wed, 08 Jul 2026 09:20:39 +0000

If you've read anything about password hashing or encryption, you've run into all three names: PBKDF2, bcrypt, Argon2. They get lumped together as "ways to turn a password into something safe to store or use," but they were built for different problems, at different times, and they don't defend against the same attacks equally well. Here's what each one actually does, where they diverge, and why FileX derives its encryption keys with PBKDF2 rather than the others.

What a key-derivation function is for

A password like correct horse battery staple is not usable directly as a cryptographic key, and it's not safe to check by comparing it to a plain stored copy either. A key-derivation function (KDF) — sometimes called a password-hashing function in the login context — takes the password plus a random salt and runs it through a deliberately expensive one-way computation. Two properties matter:

The salt makes every derivation unique, even for two people who pick the same password, so an attacker can't precompute one giant table of results and reuse it against every target.
The cost (iterations, memory, or both) makes each guess slow. An attacker who steals a salt and a ciphertext (or a stored hash) still has to pay that cost for every single password they try. That's the entire point — the cipher or the login check is rarely the weak link; how expensive it is to brute-force the password is.

PBKDF2, bcrypt, and Argon2 all satisfy this shape. Where they differ is what they make expensive.

PBKDF2: CPU-hard, standardized, everywhere

PBKDF2 (Password-Based Key Derivation Function 2) dates to 2000 and is specified in RFC 2898. It derives a key by running an underlying HMAC (commonly HMAC-SHA256) over the password and salt thousands of times in sequence. The only cost knob is iterations — more repetitions, more CPU time, no memory requirement beyond the hash itself.

That single-dimension cost is PBKDF2's main weakness: it parallelizes cleanly on GPUs and ASICs, which can run huge numbers of hash iterations concurrently far cheaper than a general-purpose CPU can. NIST SP 800-63B sets the floor at "typically at least 10,000 iterations," while the current OWASP Password Storage Cheat Sheet recommends 600,000 iterations for PBKDF2-HMAC-SHA256 in new systems specifically because commodity GPU cracking has gotten so much faster since the function was designed. PBKDF2 is still considered sound — it just needs a high, regularly-revisited iteration count to stay expensive against modern hardware.

bcrypt: built for login checks, not general key derivation

bcrypt (1999) wraps the Blowfish cipher into a password-hashing scheme with a configurable, exponential cost factor. It was a real improvement over unsalted or fast-hashed passwords at the time, and OWASP still lists it as an acceptable choice with a work factor "as large as verification server performance will allow, with a minimum of 10."

Two things limit it outside login-check use cases: it silently truncates input past 72 bytes, and — like PBKDF2 — its cost is CPU time only, so it doesn't resist a well-funded, memory-rich cracking rig as well as a memory-hard function does. It's also not part of any Web Crypto API standard, so a browser can't produce it without shipping a separate implementation.

Argon2: memory-hard, the modern default

Argon2 won the Password Hashing Competition in 2015 and is standardized in RFC 9106. Its cost has three independent dials: iterations (time), memory (how much RAM each computation must hold), and parallelism. That memory requirement is the important change — a GPU or ASIC that can run millions of cheap hash operations in parallel can't cheat past a function that demands, say, 19 MiB of memory per guess. Memory is expensive to parallelize at scale in a way that raw compute isn't.

OWASP now recommends Argon2id (a hybrid variant resistant to both side-channel and GPU-style attacks) as the first choice for new password-hashing systems, falling back to PBKDF2 only when FIPS-140 compliance is required.

The three, side by side

	PBKDF2	bcrypt	Argon2id
Defined	RFC 2898 (2000)	1999, no formal RFC	RFC 9106 (2021)
Cost dimension	Iterations (CPU only)	Cost factor (CPU only)	Time + memory + parallelism
GPU/ASIC resistance	Weaker — parallelizes well	Moderate	Strong when memory is tuned high
Input limits	None significant	Truncates past 72 bytes	None significant
Native in the browser (Web Crypto API)	Yes	No	No
FIPS-140 status	Approved	Not a NIST/FIPS algorithm	Not currently FIPS-approved

Why FileX uses PBKDF2

FileX derives the AES-256 key for every .filex container with PBKDF2-HMAC-SHA256, a random 16-byte salt, and 250,000 iterations, calling crypto.subtle.deriveKey directly — the Web Crypto API built into every modern browser. That's the deciding factor: SubtleCrypto.deriveKey supports PBKDF2, HKDF, and ECDH natively. It does not support Argon2 or bcrypt. Getting either of those into the browser means shipping a third-party WebAssembly implementation and trusting it the way you'd trust any dependency — which cuts against FileX's rule of using only the browser's own audited, self-hosted crypto primitives with nothing extra to fetch or verify.

That's an honest trade-off, not a claim that PBKDF2 is the strongest KDF available. Argon2id's memory-hardness is a genuine advantage against large-scale GPU cracking, and if you're designing a server-side login system today, OWASP's guidance to prefer Argon2id over PBKDF2 is worth following. FileX's use case is different in one respect but not immune to the same math: it derives a file encryption key from a password, not a login-check hash, but an attacker who obtains a .filex file still faces the same offline brute-force economics — the salt and iteration count are exactly what slow them down. FileX's 250,000 iterations sit well above the NIST floor of 10,000, though below OWASP's newer 600,000-iteration figure for stored password verifiers; iteration counts are a moving target as hardware gets faster, which is why the cheat sheets keep raising them.

The practical upshot for you: the KDF is only half the defense. A long, random password does more for your file's security than any iteration count can compensate for on its own — generate one in your browser with the same zero-upload guarantee. For the full picture of how the derived key gets used — AES-256-GCM, the random IV, the authentication tag that rejects tampering — see how AES-256-GCM keeps your files safe.

Takeaway

All three — PBKDF2, bcrypt, Argon2 — exist to make password guessing slow, not to make encryption itself stronger.
PBKDF2 and bcrypt cost CPU time only; Argon2 also costs memory, which is why it resists GPU/ASIC cracking better.
Web browsers only implement PBKDF2 natively (via the Web Crypto API), which is why FileX — and most in-browser crypto — uses it rather than Argon2 or bcrypt.
The password you choose still matters more than the KDF choice. Encrypt a file in your browser — nothing is uploaded, and the live monitor on the page proves it.