Cryptor (AES-256) — Tips & Tricks
Strategy and pitfalls for Cryptor: password strength, no key recovery, the visible password field, legacy migration, and combining it with other tools.
Back to overview: Cryptor (AES-256) · Open the live tool: www.jpkc.com/tools/cryptor/
Cryptor is quick to operate — but with encryption, the devil is in the details. This page collects what matters in practice. The technical groundwork for it is in the manual.
The password is everything — and not recoverable
Cryptor is symmetric encryption: the same password encrypts and decrypts. From that follows the single most important rule:
- Lose the password and the ciphertext is irretrievably lost. There's no reset, no back door, no recovery — that's not a flaw, it's the point of genuine encryption. Record the password somewhere safe (a password manager) before you hand the ciphertext on.
- A weak password makes the strong crypto worthless. AES-256 and 300,000 PBKDF2 iterations help little if the password is
secret123. Use the Generate secure password button (64 random characters) or a long, unique password from your manager. - A minimum of 8 characters is what the tool demands to encrypt — that's a floor, not a guideline. For confidential content, use considerably more.
Transmit password and ciphertext separately
The ciphertext is only as secure as the channel the password travels on. Never send the two together in the same message. Proven approach: the ciphertext by email or chat, the password by another route (phone, Signal, in person). Anyone who intercepts both in the same inbox otherwise has everything.
The password field is visible
Unlike a typical login field, Cryptor shows the password in the clear (not as dots). That's handy for avoiding typos — but mind shoulder surfers, screen sharing, and screenshots. Tidy up with Clear when you're done: it wipes the Message field and the password field in one go.
GCM detects tampering — use that
Because Cryptor uses AES-256-GCM (authenticated encryption), a successful decryption is also an integrity proof: if even a single byte of the ciphertext had been altered, decryption would fail. So if a block decrypts, you can be sure it's unchanged from you — and wasn't garbled in transit. If Decrypt fails, either the password is wrong or the ciphertext is damaged (e.g. a character lost while copying).
Every run produces a different ciphertext
Don't let it throw you: encrypting the same text with the same password twice gives you two different Base64 blocks. That's correct — the salt and IV are newly random on each run. Both blocks decrypt with the password to the same plaintext. An identical result would, on the contrary, be a warning sign.
Migrate legacy messages
If you encounter an old ciphertext (begins with U2FsdGVkX1…), Cryptor still reads it but no longer produces it. Treat such finds as a migration task: Decrypt (legacy is detected automatically) → follow the "Re-encrypt for better security" hint → click Encrypt straight away to store the message in the modern format. That way you gradually move everything onto AES-256-GCM.
Compatibility: don't count on third-party tools
Cryptor's modern output format is a custom layout — Base64(salt + iv + ciphertext + tag) with the parameters listed in the manual. It is not designed to be decrypted by openssl enc or other tools out of the box. So plan Cryptor as a closed loop: what you encrypt here, you decrypt here again. (The older Salted__ legacy format was OpenSSL-style — but Cryptor can only read it, not produce it.)
No history — save results in time
For security reasons, Cryptor stores nothing between runs. Reload the page or close the tab and everything is gone. So save a ciphertext or a decrypted text in time with Copy (clipboard) or Save (file encrypted.txt) before you leave the page.
The browser needs HTTPS
The Web Crypto API only runs in a secure context. If Encrypt/Decrypt stay greyed out, or a message says your browser doesn't support modern encryption, check that you really opened the page over HTTPS (https://www.jpkc.com/tools/cryptor/) and in a current browser.
Combining with other JPKCom tools
- Password & key generator — when you want more control over the password's length and character set than the built-in button offers.
- Hash generator — put a checksum over the encrypted file to spot corruption later, before you even enter the password.
- QR code generator — hand over a short ciphertext as a QR code (the password separately, of course).
- PKI / certificates — when a shared password isn't practical and you need asymmetric cryptography.
The full reference is in the manual, concrete walkthroughs in the examples. You can try everything in the tool.