AES-256 text encryption

What that encrypted string actually contains

The output looks like one solid block of Base64, but it is really three things travelling together: the random salt used to turn your password into a key, the random IV used for this one encryption, and the ciphertext itself. None of the packaging is secret — salt and IV are allowed to be public, which is precisely why the whole string can be posted in an e-mail, a chat or a ticket without weakening anything. It also explains something that surprises people: encrypt the same text with the same password twice and you get two completely different strings. Both decrypt fine. A fresh salt and IV are drawn every time, so no observer can even tell that two messages contain the same text — that is a feature doing its job, not an inconsistency.

Tampering shows up as failure, not garbage

AES-GCM is an authenticated mode, and that changes what failure looks like. If a single character of the encrypted string is altered in transit — by a mangled copy-paste, an over-helpful messenger app, or someone actually meddling — decryption does not produce corrupted text. It refuses outright. A wrong password fails the same way. So a successful decrypt quietly certifies two things at once: the password was correct, and the string arrived exactly as it was created. That property is worth more than it first sounds — with older, unauthenticated encryption a subtly corrupted message could decrypt into subtly corrupted text, and nobody would notice until the wrong number was already in the wrong contract. If a string that should work keeps failing here, suspect the copy first — a missing final character or an added line break from a chat app is far more common than a forgotten password, and re-copying the original string fixes it in seconds.

The password is the whole fortress

The mathematics here is not the weak point and never will be — the password is. The 250,000 rounds of key stretching make every guess expensive, but no amount of stretching rescues something like summer2026, and attackers guess the obvious things first. Length beats cleverness: four unrelated words are stronger than eight symbols, and far easier to read out over the phone, which is exactly how a good password should travel — by a different route than the encrypted text. Be equally clear-eyed about the other side of that strength: there is no recovery. Lose the password and the text is gone for good, with no reset link and no backdoor, not even for us — nothing ever left your browser for there to be a copy of.

What encryption does not hide

Honesty about the edges: encrypting the text hides its content, not its existence. Anyone watching the channel still sees that you sent something, roughly how long it is, and when. It also cannot protect a message from the person you send it to — encryption guards the journey, not the recipient's judgement, so share the password only with someone you would trust with the plain text itself. And the moment your contact decrypts it, the result is ordinary plain text again — protected by nothing the instant it is pasted into a document or forwarded on. So treat this as a strong envelope for the journey, not a permanent vault. Two natural companions round the workflow off: the password generator produces the kind of long random passphrase this deserves, and when the thing you need to protect is a whole document rather than a piece of text, the PDF lock tool seals it into a PIN-protected PDF instead.

How this keeps text private

Your password never travels anywhere — a unique encryption key is derived from it locally (PBKDF2, 250,000 iterations) with a random salt, then AES-256-GCM encrypts the text with a random IV. Salt and IV are bundled into the output string so decryption only needs the password, not any extra values to keep track of.