XOR encryption online is a browser tool that combines every plaintext byte with the matching byte of a repeating UTF-8 key using the bitwise exclusive-or operator and shows the resulting bytes in both hexadecimal and Base64 so the same ciphertext can be carried through whichever channel the recipient expects. The XOR Encryption Online page implements exactly that construction in your browser, with no account, no upload, and no server-side key handling: the page reads the plaintext and key, encodes both as UTF-8 with the TextEncoder API, and applies the XOR locally using index modulo keyLength as the repetition rule. Decrypt mode reverses the operation with strict hex or Base64 parsing and fatal UTF-8 validation, which means many wrong-key attempts surface as a visible error instead of silent replacement characters. Both ends must agree on three things: the key text including case and spaces, the key repetition rule, and which output representation was used. The rest of this guide walks through the exact steps, the hex-versus-Base64 trade-offs, the UTF-8 conventions, and the security limits you should respect before sending a reversible XOR message.
What the Tool Produces From Your Plaintext and Key
When you want to send a message that the recipient can reverse with a shared key, the XOR cipher is one of the simplest constructions that is symmetric, reversible, and short enough to implement by hand. XOR Encryption Online applies that exact construction to UTF-8 bytes in your browser and exposes the same ciphertext as hex and Base64 so you can pick whichever shape fits the channel. The page reads the plaintext and key, performs the XOR with TextEncoder and the bitwise XOR operator, and renders the result locally. There is no upload step, no server-side key, no account, and no telemetry to clean up afterwards.
What you give the tool: a plaintext string and a key string. What you get back: an identical byte sequence rendered twice. What the recipient needs: the rendered ciphertext in one of the two supported forms, plus the exact same key text. Everything else, including byte encoding, key repetition, and representation switching, follows one fixed rule so two browsers running the same page produce identical output. To keep conversion, rendering, and copying responsive, the page caps both the plaintext and the key at 100,000 UTF-8 bytes each; longer messages are not accepted.
Encrypt and Decrypt a Message Step by Step
The full cycle takes a few actions in the same tool. To keep both ends in sync, share the key out of band and pick one output representation before you copy anything.
- Open XOR Encryption Online and choose Encrypt mode.
- Enter the plaintext exactly as you want it sent, then enter the key text. The key field is treated as UTF-8 characters, not as hex, so the word key becomes the bytes 6B 65 79.
- Run the transform. The page XORs every plaintext byte with keyBytes[index modulo keyLength] using the bitwise XOR operator and shows the same bytes as lowercase hex and standard Base64.
- Copy the hex or Base64 form you intend to send, and tell the recipient which one you used. Switching representation does not change the underlying bytes.
- To recover text, switch to Decrypt mode, choose the matching representation, paste the ciphertext, and enter the identical key including case and spaces.
- If parsing fails on hex, check that you have an even number of hex digits and no stray characters. If parsing fails on Base64, verify the alphabet, the padding, and that your transport did not add whitespace.
Hex vs Base64: Choosing the Output Representation
Both representations carry the same bytes; they only differ in how those bytes are written. Pick the form that fits the channel the recipient can read.
| Aspect | Hexadecimal | Base64 |
|---|---|---|
| Length | Two characters per byte, so roughly twice the byte count | About four characters per three bytes, typically shorter |
| Character set | 0-9 and a-f (or A-F); only safe ASCII | A-Z, a-z, 0-9, +, / with = padding |
| Inspectability | Easy to read byte-by-byte and to align with raw byte dumps | Compact, but harder to eyeball against a byte stream |
| Whitespace handling | Ignored for convenience, so line wrapping survives | Ignored too, but most transport layers preserve it |
| Best fit | Debug output, capture-the-flag writeups, protocol fields | URLs, JSON strings, email bodies, paste-friendly fields |
Because both forms carry the same ciphertext, a recipient can copy the hex result into a separate tool such as the Base64 to Hex Converter and convert it without re-running the cipher.
Key Handling: UTF-8 Text, Not a Hex String
The key field is treated as plain UTF-8 text. The three-letter word key becomes the three bytes 6B, 65, 79 in that exact order. If you instead type the literal characters 6, B, 6, 5, 7, 9 into the key field, the tool uses six bytes: 36 42 36 35 37 39. This distinction is the most common reason the same key produces different ciphertext in a different tool.
Tools that interpret the key as hexadecimal bytes are following a different convention. They would take the string 6B6579 and turn it into the three bytes 6B, 65, 79. To match such a tool from this page, you would have to type the actual characters k, e, y, not the digits of their codepoint representation. Case matters: the uppercase word Key is bytes 4B 65 79 and produces a different ciphertext than the lowercase key. Spaces inside the key are significant; whitespace inside the encoded ciphertext is ignored for convenience, but the key bytes themselves are not trimmed or normalized.
Empty plaintext and empty key are both rejected. If you need a longer key, every additional character adds another byte to the cycle, and longer keys cost more brute-force work, although they do not by themselves turn XOR into secure encryption.
Unicode, Multi-byte Letters, and Where Bytes Are Spent
This implementation XORs UTF-8 bytes, not JavaScript UTF-16 code units and not user-perceived grapheme clusters. The difference becomes visible the moment your message includes accents, scripts outside Latin, or emoji. A character like é is two bytes in UTF-8, and a typical emoji is four. Each of those bytes consumes one slot of the repeating key cycle, so the key index advances faster than the visible character count.
If you compare ciphertext against a command-line program, a scripting language library, or another web tool, make sure both sides agree on three things: the byte encoding of the plaintext (UTF-8 here), the byte encoding of the key (UTF-8 here), and the key repetition rule (index modulo keyLength here). When all three match, the ciphertexts match. When they do not, even a one-byte difference at the start of the key cascades through every subsequent byte.
Security Reality: What Repeating-Key XOR Can and Cannot Do
Repeating-key XOR is a reversible obfuscation, not a modern cipher. There is no checksum, no authentication tag, no salt, no nonce, no password stretching, and no key-management system. The page itself flags this in plain language and recommends a reviewed authenticated-encryption system for anything sensitive. For real workloads, consider a vetted cipher packaged in an authenticated mode, such as AES-256-GCM; the AES Encryption Online tool produces a portable authenticated package that protects both confidentiality and integrity.
Even against passive observers, repeating-key XOR has well-known weaknesses. The key repeats, so patterns in the plaintext leak through as periodic patterns in the ciphertext. Known-plaintext attacks can recover key bytes directly. Short keys are especially weak because the period is short. There is also no integrity: an attacker who can flip bits in the ciphertext will change the corresponding plaintext bytes on the other end, and the recipient has no way to notice. For a deeper walk-through of these limits, see Is XOR Encryption Secure? A Repeating-Key Reality Check. Use this tool for harmless puzzles, interoperability checks, capture-the-flag exercises, and learning. Do not use it for passwords, personal records, payment details, private keys, or any information where confidentiality or integrity matters.
Troubleshooting Mismatched Results
Two users following the same convention will always land on the same bytes. When results differ, walk through these checks in order. First, confirm the key text character-by-character, including case and any invisible whitespace, since a single different byte shifts every subsequent byte. Second, confirm that the transport did not trim, wrap, or rewrite the ciphertext, and that you picked the same hex vs Base64 representation on both ends. Third, confirm that both sides are working in UTF-8 for both the plaintext and the key; if one side treats the key as hex bytes, the bytes will diverge.
Decryption can still produce readable text with a wrong key, especially for short ASCII messages, because random byte sequences occasionally form valid UTF-8 by chance. A successful UTF-8 decode is therefore not proof the key is right. To verify, look for repeated structure, compare against an independent hash, or send a small known plaintext first and confirm the bytes match. If decryption throws a fatal UTF-8 error, treat that as evidence the key is wrong, not as a bug in the page.
Related reading: Change File Encoding to UTF-8 and Download It.