Text Encryptor

Encryption vs. Encoding — A Critical Distinction

These terms are confused constantly, and the confusion matters because confusing them creates false security. Encoding transforms data into a different format for compatibility or transmission — Base64, URL encoding, and binary are encoding schemes. They are fully reversible without any key. Anyone can decode Base64. Encryption transforms data so that it cannot be read without a secret key. Without the correct key, an encrypted ciphertext is computationally indistinguishable from random noise. This tool performs real encryption using AES-256 — not encoding, not obfuscation, not ROT13.

AES-256 (Advanced Encryption Standard with a 256-bit key) is the same algorithm used by governments, militaries, financial institutions, and secure messaging apps globally. "256-bit" refers to the key length: there are 2²⁵⁶ possible keys — a number so large that exhaustive search is computationally impossible with any hardware that exists or could feasibly be built. Breaking AES-256 by brute force would require more energy than the sun produces. The security of AES-256 rests entirely on keeping the key (your password) secret — the algorithm itself is public, standardised, and published by NIST.

How the Encryption Works — Key Derivation and Cipher Mode

You provide a password; the tool derives a 256-bit AES key from it using PBKDF2 (Password-Based Key Derivation Function 2). PBKDF2 runs your password through HMAC-SHA256 thousands of times with a random salt. The iteration count makes brute-force password guessing expensive — an attacker who obtains the ciphertext must perform thousands of hash operations for every password they test. The salt ensures that two people encrypting the same text with the same password produce different ciphertexts, preventing precomputed lookup attacks.

The derived key encrypts your text using AES in CBC mode (Cipher Block Chaining). CBC processes text in fixed 16-byte blocks, XORing each block with the previous ciphertext block before encrypting — this chaining means identical input blocks produce different ciphertext blocks, which prevents pattern analysis. A random Initialisation Vector (IV) is generated for each encryption operation and prepended to the output, so the same text encrypted twice produces different ciphertext each time. The final output is Base64-encoded so it can be safely handled as text rather than raw binary bytes.

Practical Use Cases for Client-Side Text Encryption

The most common use is storing sensitive notes in inherently insecure locations. If you keep notes in a cloud service you don't fully trust, or in a shared document, encrypting the sensitive portions means even someone with full access to the document cannot read the content without your password. This is a meaningful protection for things like account recovery codes, private journal entries stored in cloud notes, or sensitive business information in shared workspaces.

A second use case is sharing secrets over channels you don't control. Encrypted text sent via email, SMS, or a public messaging platform means an eavesdropper who intercepts the message sees only ciphertext. The recipient decrypts it with a password shared through a separate channel. This isn't a substitute for end-to-end encrypted messaging apps like Signal for ongoing communication, but it's useful for one-off secret sharing when you're constrained to a specific channel. For tracking and organising plain sensitive text before encryption, the Find and Replace tool handles bulk text cleanup.

What This Tool Cannot Protect Against

Encryption protects data at rest and in transit from people who don't have your key. It does not protect against all threat models. If someone has malware on the device where you decrypt, they can capture your text before or after encryption. If your password is weak (short, based on dictionary words, or reused from another service), brute-force attacks against the PBKDF2 output become feasible. If someone coerces or tricks you into providing the password, encryption provides no protection.

Additionally, this tool is designed for text encryption — notes, messages, short sensitive content. It is not a file encryption tool, not a full-disk encryption solution, and not a substitute for proper secret management infrastructure in a production environment. For application secrets, credentials, and API keys, use a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or a password manager with secure notes). This tool covers the personal and informal use case: encrypting a piece of sensitive text for storage or transfer when formal infrastructure isn't available or appropriate.

Password Strength — The Weakest Link

AES-256 cannot be broken by attacking the cipher. The only practical attack against properly implemented AES-256 encryption is attacking the password. A weak password (under 12 characters, based on words, names, or predictable patterns) can be cracked via dictionary attack even if PBKDF2 slows each attempt. A strong password for encryption purposes is random, at least 16 characters, and drawn from a large character set — or a passphrase of at least 5 unrelated random words (which is much easier to remember while providing equivalent entropy to a shorter random string).

The password used to encrypt must be communicated securely to anyone who needs to decrypt. Never send the password through the same channel as the ciphertext — if an attacker intercepts both, they have everything they need. Use a separate channel for the password: voice call, a different messaging app, or an in-person exchange. For other text transformation tasks in your workflow, the Text to Binary Converter handles encoding operations, and the Remove Extra Spaces tool cleans up text before encryption when needed.

✓Verified by ToollyX Team · Last updated June 2026