# 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. Source: https://www.jpkc.com/db/en/tools/cryptor/tips/ Back to overview: [Cryptor (AES-256)](https://www.jpkc.com/db/en/tools/cryptor/) · Open the live tool: [www.jpkc.com/tools/cryptor/](https://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](https://www.jpkc.com/db/en/tools/cryptor/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](https://www.jpkc.com/db/en/tools/generator/)** — when you want more control over the password's length and character set than the built-in button offers. - **[Hash generator](https://www.jpkc.com/db/en/tools/hash/)** — put a checksum over the encrypted file to spot corruption later, before you even enter the password. - **[QR code generator](https://www.jpkc.com/db/en/tools/qr/)** — hand over a short ciphertext as a QR code (the password separately, of course). - **[PKI / certificates](https://www.jpkc.com/db/en/tools/pki/)** — when a shared password isn't practical and you need asymmetric cryptography. --- The full reference is in the [manual](https://www.jpkc.com/db/en/tools/cryptor/manual/), concrete walkthroughs in the [examples](https://www.jpkc.com/db/en/tools/cryptor/examples/). You can try everything in the [tool](https://www.jpkc.com/tools/cryptor/).