How does this know if the passphrase is wrong?

AES-GCM includes a built-in authentication tag as part of the ciphertext. If the passphrase (and therefore the derived key) is wrong, or the blob has been altered, decryption fails its authentication check rather than silently producing garbage text, and the tool reports this as a clear, friendly error.

Does this only work with blobs from CSV Encryptor?

Yes, it expects the exact packing format CSV Encryptor produces, a base64 string containing a 16-byte salt, a 12-byte IV, and AES-GCM ciphertext concatenated in that order.

What if I paste something that isn't valid base64?

The tool catches the decode failure immediately and tells you the input doesn't look like valid base64 output from CSV Encryptor, rather than proceeding into a confusing downstream error.

Is anything sent to a server during decryption?

No, decryption happens entirely client-side via the Web Crypto API. Neither the encrypted blob nor your passphrase ever leaves your browser.

CSV Decryptor - Decrypt AES-256-GCM CSV Blobs

Overview

Introduction

CSV Decryptor is the other half of CSV Encryptor: given the base64 blob it produced and the original passphrase, it recovers the exact original CSV text.

Because AES-GCM is an authenticated cipher, decryption doesn't just fail silently on a wrong passphrase or corrupted data, it fails loudly and clearly, which this tool surfaces as a friendly, specific error message.

What Is CSV Decryptor?

The inverse operation to CSV Encryptor: it unpacks a base64 blob back into its salt, IV, and ciphertext components, re-derives the AES key from your passphrase using the identical PBKDF2 parameters, and decrypts.

It expects exactly the packing format CSV Encryptor produces, salt then IV then ciphertext, concatenated and base64-encoded, so it only decrypts blobs produced by that specific tool (or anything else using the identical format).

How CSV Decryptor Works

The base64 input is decoded to raw bytes; the first 16 bytes are the salt, the next 12 are the IV, and everything after that is the AES-GCM ciphertext (which carries its own authentication tag).

Your passphrase and the extracted salt are run through the same PBKDF2 parameters (250,000 iterations, SHA-256) used during encryption to re-derive the identical AES key, which is then used to decrypt the ciphertext with the extracted IV.

When To Use CSV Decryptor

Use this whenever you need to read back a CSV that was encrypted with CSV Encryptor, you'll need both the base64 blob and the original passphrase.

It's also useful for verifying an encrypted blob is valid and recoverable immediately after encrypting, before deleting your only plaintext copy.

Often used alongside CSV Encryptor and CSV Anonymizer.

Features

Advantages

AES-GCM's built-in authentication means a wrong passphrase or corrupted blob is caught immediately and reported clearly, rather than silently returning garbled text.
Fully symmetric with CSV Encryptor's exact parameters, so anything that tool produces decrypts correctly here with the right passphrase.
Runs entirely client-side, your encrypted data and passphrase are never transmitted anywhere.

Limitations

Only decrypts blobs in CSV Encryptor's exact format (salt || iv || ciphertext, base64-encoded); other encrypted formats or tools aren't supported.
There's no passphrase recovery or hint mechanism, a forgotten passphrase means the data is permanently unrecoverable.

Examples

Decrypting with the correct passphrase

Input

blob: "<base64 from CSV Encryptor>", passphrase: "correct horse battery staple"

Output

id,name
1,Ada

With the exact passphrase used to encrypt, the original CSV text is recovered byte-for-byte.

Decrypting with the wrong passphrase

Input

blob: "<base64 from CSV Encryptor>", passphrase: "wrong-guess"

Output

(error: Decryption failed. The passphrase may be wrong, or the blob wasn't produced by CSV Encryptor.)

AES-GCM's authentication check fails immediately on a wrong key, so the tool reports a clear error instead of returning corrupted or garbled text.

Best Practices & Notes

Best Practices

Copy the base64 blob exactly, including its full length, truncating it even slightly will cause decryption to fail.
Double-check for typos in the passphrase before assuming the blob itself is corrupted, a wrong passphrase and a corrupted blob produce the same generic authentication failure.
Keep the passphrase and the encrypted blob stored separately, so a leak of one alone doesn't expose the data.

Developer Notes

Uses identical PBKDF2 parameters (250,000 iterations, SHA-256) and packing offsets (16-byte salt, 12-byte IV) to CSV Encryptor by construction, any drift between the two tools' constants would make previously encrypted blobs permanently undecryptable, so both share the same literal constant values rather than importing from a shared module across category boundaries.

CSV Decryptor Use Cases

Recovering the original CSV text from a passphrase-protected encrypted blob
Verifying an encrypted blob is valid and correctly recoverable right after encrypting it
Testing that a system correctly rejects a tampered or corrupted encrypted CSV blob

Common Mistakes

Pasting a truncated or partially-copied base64 blob, even one missing character will cause decryption to fail.
Assuming a decryption failure always means a wrong passphrase, a corrupted or incomplete blob produces the identical generic error.

Tips

If decryption fails, first re-copy the blob in full before suspecting the passphrase.
Use CSV Viewer afterward to quickly inspect the recovered CSV in table form.

CSV Decryptor