Encrypt Text Online: Free AES Encryption Without Software

You have a piece of text that needs to stay private. A password, a personal note, sensitive instructions, financial details, or a message meant for only one person's eyes. You could install encryption software like GPG, learn command-line tools, or set up a PGP key pair. Or you could encrypt it right now, with nothing but a browser tab, in about 15 seconds.

Online encryption has matured to the point where you no longer need to download anything to protect sensitive text with military-grade encryption. Here is how it works, why it is safe, and how to do it.

How AES-256 Encryption Works

AES stands for Advanced Encryption Standard. The "256" refers to the key length in bits. It is the same encryption standard used by the U.S. government for classified information, by banks for financial transactions, and by every modern VPN service.

The Basic Process

1. Plaintext -- Your original readable message
2. Key -- A password or passphrase that controls the encryption
3. Encryption -- AES algorithm transforms plaintext into ciphertext using the key
4. Ciphertext -- The encrypted output, which looks like random characters
5. Decryption -- The same key reverses the process, recovering the original plaintext

Why AES-256 Is Considered Unbreakable

The 256-bit key means there are 2^256 possible combinations. That is approximately 1.15 x 10^77 -- a number so large that if every atom in the observable universe were a supercomputer trying every possible key, it would still take longer than the age of the universe to crack a single AES-256 encrypted message by brute force.

Symmetric vs. Asymmetric Encryption

AES is symmetric encryption, meaning the same key encrypts and decrypts. This is different from asymmetric encryption (like RSA or PGP), where you have a public key and a private key. Symmetric encryption is faster and simpler, but it requires you to share the key with your recipient securely.

End-to-End Encryption Explained

"End-to-end encryption" (E2E) means the encryption and decryption happen on the endpoints -- your device and the recipient's device -- and nowhere in between.

When a service claims E2E encryption, it means:

• The server never sees the plaintext
• The password never leaves your browser
• Even if the server is hacked, attackers only get ciphertext (useless without the key)

This is different from "encryption in transit" (HTTPS), which protects data between your browser and the server, but the server itself can read your data.

Type	Your Browser	Server	Recipient
No encryption	Readable	Readable	Readable
Encryption in transit (HTTPS)	Readable	Readable	Readable
Server-side encryption	Readable	Encrypted at rest, readable in memory	Readable
End-to-end encryption	Readable	Encrypted (unreadable)	Readable
Server-side, key from your password	Readable	Encrypted; openable only while the password is supplied	Readable

Not All Server-Side Encryption Is the Same

"Encrypted" covers two very different situations, and one question separates them: can the service decrypt your note on its own?

• If the service picked the key and kept it, yes. A breach, a curious employee or a subpoena is enough, because everything needed to open your note sits on their side.
• If the key comes from a password only you and your recipient know, no. What is stored stays inert until someone supplies that password.

Many note services take the first route, and it is why a leaked link is a leaked secret there: the link is all it takes to open the note. A password you never put in the link changes that -- and it is the model LOCK.PUB is built on.

How LOCK.PUB Handles Encryption

Memos are encrypted on our servers with a key built from your password, and that key is never stored anywhere:

When You Create a Memo

1. You type your text in the browser
2. You set a password
3. The text and the password travel to LOCK.PUB over HTTPS
4. The server combines your password with a secret of its own -- one that lives outside the database -- and encrypts the text with the result
5. Your secret text is kept only as ciphertext, alongside a salted scrypt verifier of your password -- never the plaintext, and never the password itself

When the Recipient Opens the Memo

1. They enter the password
2. Their browser sends it over HTTPS
3. The server checks it against the stored verifier -- a match it can confirm without your password ever being written to our database
4. On a match, the key is rebuilt from the password and our secret, the memo is decrypted, and the text is returned
5. The plaintext appears in the browser -- and if you set a one-time view (Pro), the link stops working right there

The question that matters is not only where encryption happens, but whether the server can decrypt on its own. Ours cannot: opening a stored memo takes your password, which we never store, plus a secret of ours that is not kept in the database. So the memo sits inert until someone supplies that password, and a copy of the ciphertext on its own cannot be guessed open. Two features go further. Chat, board and location content is encrypted in your browser before it is uploaded. And a request link is genuinely end-to-end: your browser builds a key pair and locks the private half with an unlock password that never leaves your device, so only you can open what people send you.

Step-by-Step: Encrypt Text with LOCK.PUB

1. Go to LOCK.PUB and select "Memo"
2. Paste or type your text -- anything from a single password to a multi-paragraph document
3. Set a strong password -- this is your half of the encryption key, so make it good
4. Write the public introduction -- the one line visitors see before they enter the password, so keep the secret part out of it
5. Choose an expiration (Pro) -- when should the link stop opening?
6. Copy the generated link and share it with your recipient
7. Share the password through a separate channel (phone call, different messaging app, in person)

The text is now AES-encrypted and accessible only to someone with both the link and the password.

Choosing a Strong Password

Your password is the part of the encryption key only you control, so its strength directly determines the security of your encrypted text.

Password Type	Example	Security Level
Common word	password123	Extremely weak
Personal info	john1990	Weak
Random short	kR7#mP	Moderate
Passphrase	correct-horse-battery-staple	Strong
Random long	4j&Km9!pQx2@Hn5v	Very strong

Best practice: use a passphrase -- three to five random words separated by dashes or spaces. Passphrases are easier to remember than random strings and harder to crack than short passwords.

When to Use Online Encryption

Sharing Passwords

Need to send a colleague their new account password? Encrypt it in a LOCK.PUB memo rather than sending it in plain text over Slack or email.

Sensitive Instructions

Medical dosage information, security alarm codes, safe combinations, server credentials -- anything you would not want a third party to read.

Legal or Financial Details

Bank account numbers, tax IDs, contract terms -- information that could cause harm if intercepted.

Personal Messages

Love letters, confessions, surprise plans -- sometimes privacy is about emotion, not just security.

Limitations to Know

Password Sharing Is Your Responsibility

AES encryption is only as secure as your password management. If you send the memo link and the password in the same email, you have effectively left the vault door open with the key taped to it.

Your Password Is Your Half of the Lock

For memos, the key takes two things: your password and a secret of ours that is never kept in the database, which is why stolen ciphertext alone cannot be run through a dictionary of guesses. Your password is the half that is yours to get right, so make it strong -- a weak password is a weak key, no matter how good the cipher is. And for the features that do encrypt in the browser -- chat, board, location, request links -- a compromised browser or malicious extension bypasses the encryption entirely, so use trusted devices.

No Recovery Without the Password

If you forget the password, the text can never be opened again. There is no "forgot password" option because the password is never stored -- only a salted verifier of it, which cannot be reversed. This is a feature, not a bug -- but it means you need to remember or securely store the password.

Encrypt Without the Learning Curve

You do not need to understand cryptographic theory to protect your text. LOCK.PUB handles the AES-256 encryption automatically, every time you create a memo, with a key that needs both a password we never store and a secret of ours that is not in the database. Your secret memo never sits in our database as readable text. The math is battle-tested. All you need to provide is a good password.

Encrypt Text Now on LOCK.PUB -->