Local Text Encryptor
Preparing tool controls…
Local Text Encryptor At a Glance
A local text encryptor turns readable text into an encrypted package that can be opened only with the original passphrase. Enter a note, choose Encrypt, confirm a passphrase, and save the resulting JSON. To recover the note, choose Decrypt, paste the package, and enter the same passphrase. This tool uses AES-256-GCM for authenticated encryption and PBKDF2-SHA256 to derive a key from the passphrase. It generates a fresh random salt and initialization vector for each encryption, so two operations on identical text should produce different packages even with the same password. The package includes everything needed for decryption except the passphrase.
Encryption is appropriate when you need to share a private message through a channel that you do not want to trust with the readable text, or when you want a portable encrypted note. It does not turn a weak passphrase into a strong secret, protect against malicious software on the device, or erase the original from a clipboard, draft folder, or browser history. The strongest precaution is to prepare text on a trusted computer and keep the passphrase away from the encrypted package.
How to Encrypt and Decrypt Text
Type or paste the message into the text field and select Encrypt text. Choose a passphrase with at least twelve characters; a longer, unusual phrase is preferable to a short password with predictable substitutions. Re-enter the same phrase in the confirmation field, then run the operation. The output is a structured JSON object containing the encryption format, cipher, key-derivation method, iteration count, salt, initialization vector, and ciphertext. Copy or download the entire object; saving only the last line will not provide enough information to recover your message.
To decrypt, select Decrypt package, paste the original JSON, and supply the passphrase that was used during encryption. The tool checks the package format and attempts authenticated decryption. If the passphrase is wrong or the ciphertext has been changed, it reports a failure instead of displaying plausible but incorrect text. A valid result can be copied or downloaded as a text file. A recovered note is plain text again, so treat its destination and clipboard history with the same care as the original message.
What AES-256-GCM Protects
AES-GCM combines confidentiality with an authentication check. Confidentiality obscures the content without the key. Authentication detects changes to the ciphertext, including common accidental damage when a package is copied incompletely. The tool uses a 256-bit AES key derived from the passphrase rather than asking you to manage a raw hexadecimal key. During encryption, a random twelve-byte initialization vector is created for that key operation; using a new value matters because repeating a nonce with a key can damage GCM security.
An authenticated package is not the same thing as a digital signature. Anyone who learns the passphrase can decrypt the text and create a different package that appears valid under that passphrase. The tool therefore does not prove who originally wrote a message. If you need nonrepudiation, recipient identities, access controls, or managed key rotation, those requirements belong to a system designed for secure communication rather than an individual text conversion form.
How the Passphrase Becomes an Encryption Key
Passphrases are not uniformly random cryptographic keys. PBKDF2 processes the passphrase and a new random salt repeatedly to derive an AES key. This release uses 310,000 PBKDF2-SHA256 iterations, and a supported encrypted package records its iteration count so the same key can be derived during decryption. The salt does not need to be hidden; its purpose is to make precomputed password attacks less convenient and to produce different derived keys for repeated passphrases with different salts.
The number of iterations slows legitimate decryption as well as password guessing, which is why excessively expensive settings are not automatically an improvement. The tool limits accepted derivation parameters to a reasonable range to avoid processing unexpected values from an edited package. A long random passphrase still matters more than treating the iteration count as a substitute for password quality. For generating a secret independently, a passphrase generator can provide an unpredictable starting point.
Understanding the Encrypted JSON Package
The encrypted file contains ordinary text fields that identify how the encrypted bytes were created. Values named `salt`, `iv`, and `data` use Base64URL encoding, which represents binary values using characters suitable for copying. Base64URL is an encoding, not encryption; the secrecy comes from AES-GCM and the derived key. You can store the complete JSON in a text file, but do not edit individual fields unless you intend to invalidate or replace the package.
The package format is versioned so future changes do not silently alter the meaning of an older encrypted file. This version expects AES-256-GCM with PBKDF2-SHA256 and validates sizes before attempting decryption. Save a second copy of an important package and check that you can decrypt it on the computer where you created it. An encrypted copy that cannot be opened is not a useful backup, even when the algorithm is mathematically sound.
Sharing Encrypted Notes More Safely
A practical workflow separates the encrypted payload from the passphrase. For example, send an encrypted project note through a document channel and communicate the passphrase through a different, independently secured method. Avoid including the passphrase in the filename, the same email thread, a screenshot, or adjacent text. Consider what people with access to either channel could learn from the file name and the timing of the exchange even without decrypting its contents.
Encryption also does not guarantee that deleted material is unrecoverable. If a note has already been pasted into an online document, sent through a chat, or stored in an editor's autosave history, encrypting another copy cannot retract those earlier versions. Review who can access the endpoint device, whether clipboard managers record copied text, and whether downloaded plaintext files are automatically synchronized to cloud storage. Those operational decisions are part of keeping sensitive writing private.
Limits, Errors, and Data Handling
Text is encoded as UTF-8 before encryption, and the interface accepts up to one mebibyte of UTF-8 text. Emoji and non-Latin letters may take multiple bytes, so the byte size can exceed the character count. An incorrect package, unsupported algorithm marker, invalid salt, short passphrase, or failed authentication results in an explicit error. The tool cannot recover lost passphrases, decrypt files produced by unrelated formats, or open documents protected with PDF passwords. A PDF password protector addresses a separate file format and compatibility problem.
The cryptographic operations use the browser's Web Crypto API, which normally requires a secure HTTPS page or localhost. The passphrase and decrypted text are not part of the package that gets downloaded after encryption. However, browser extensions, operating-system clipboard tools, and untrusted devices may still observe information entered on a page. For integrity comparisons rather than secrecy, a text hash generator produces a digest that does not attempt to conceal the source text.
Keeping a Recoverable Encrypted Copy
Before deleting the original note, save the encrypted JSON in two suitable locations and confirm that you can decrypt one copy with the stored passphrase. If a transfer tool alters quotation marks, wraps lines unexpectedly, or truncates the contents, the authentication check should fail instead of returning altered plaintext. This is desirable for integrity, but it means careless handling can leave you without a usable copy. A sensible naming convention records the document purpose without embedding private details in the filename. Keep the decryption phrase out of the filename and the same storage account whenever that account could be compromised.
Frequently Asked Questions About Local Text Encryption
Can I decrypt the message without the original passphrase?
No. The package deliberately excludes the passphrase, and there is no password-recovery service behind it. If you forget the secret, restoring a previous readable copy may be your only practical option. Test recovery before relying on an encrypted package as your only stored version.
Why does encrypting the same message twice give different results?
Each operation uses a new random salt and initialization vector. Those values intentionally change the derived key and encryption output while still allowing successful decryption with the same passphrase. Different ciphertext is expected and is not evidence that the message was altered.
What does an authentication error mean?
It usually means the passphrase is incorrect, the package is incomplete, or some encoded bytes were changed. AES-GCM detects these problems without returning a partially readable guess. Verify the complete JSON and password before assuming that the original message was lost.
Is Base64 the same as encryption?
No. Base64URL simply converts binary data into a portable text representation. Anyone can decode a Base64 value. The AES-GCM ciphertext inside the package remains encrypted after the Base64URL representation is decoded.
Can I encrypt an entire Word document with this tool?
This workspace encrypts UTF-8 text, not arbitrary office-file structures. Copying text out of a Word document also loses its layout and embedded images. Use a document encryption system if formatting, attachments, or access permissions need to survive intact.
Does this prevent someone from taking a screenshot of the original text?
No. Encryption protects the saved ciphertext but not a visible note on a compromised or shared screen. Consider device access, browser extensions, screen sharing, and copied plaintext before entering especially sensitive information.
Does the tool prove who sent a message?
No. Authenticated encryption verifies the ciphertext under the derived key; it does not bind the message to a person's identity. A digital signature and verified public key are different cryptographic mechanisms used for sender authentication.