How Repeating-Key XOR Produces Ciphertext
XOR Encryption Online applies a byte-wise exclusive OR between a UTF-8 plaintext and a repeating key, then serializes the resulting bytes as both lowercase hexadecimal and standard padded Base64 so the recipient can use whichever representation their system expects. The browser converts both the plaintext and the key with TextEncoder (UTF-8), walks the plaintext one byte at a time, and combines each plaintext byte with the byte at the same index in the key. When the plaintext is longer than the key, the key index wraps back to position zero and the cycle repeats, which is why the cipher is called repeating-key XOR and why the same key with the same plaintext always produces the same ciphertext on a standards-compliant browser. Hex writes two characters per byte, which makes the output easy to scan by eye for length and pattern checks. Base64 squeezes the same bytes into roughly four characters for every three bytes, so it travels cleanly through JSON, query strings, and chat boxes that strip or escape unusual characters. Switching the output format on the tool does not change the underlying XOR transform, only the printable representation. Encryption shows both forms so the sender can pick whichever representation the recipient expects; decryption accepts the matching form, parses the bytes strictly, applies the same repeating-key XOR, and runs a fatal UTF-8 decode so a wrong key usually surfaces as an explicit error rather than a quiet replacement character.
The transform runs entirely in the browser, which means the plaintext, the key, and the ciphertext never leave your machine. There is no API call, no signup, and no remote processing step. Two users who want to exchange a message simply agree on the exact key text and on which representation will travel through their transport channel, then both run the same convention locally.
For a concrete worked example, take the key word key, whose UTF-8 bytes are 6B 65 79, and apply it to the single-byte plaintext A (UTF-8 byte 41). The XOR is 41 XOR 6B = 2A, so the ciphertext begins with the byte 2A, displayed as the hex string 2a or the Base64 string Kg==. The MDN reference for the bitwise XOR operator documents the underlying operation, and the MDN TextEncoder page describes the UTF-8 encoding step that produces the byte sequence before the XOR runs.
| Property | Lowercase Hex | Standard Padded Base64 |
|---|---|---|
| Visible byte boundaries | Yes, two characters per byte | No, four characters encode roughly three bytes |
| Length for a given message | About two characters per byte (longer) | About one and a third characters per byte (shorter) |
| Where it appears most often | Debug logs, hex dumps, copy-paste of raw bytes | JSON values, HTTP headers, email and chat payloads |
| Whitespace inside ciphertext | Ignored | Ignored |
| Padding rule | None | Trailing = characters required for partial groups |
| What counts as malformed | Odd character count or non-hex digits | Characters outside the standard alphabet or wrong padding |
Run the same plaintext and key in XOR Encryption Online and confirm the result before you send it. A separate guide on picking the output format walks through the same trade-off with worked examples.
Encrypt a Message
Encryption takes UTF-8 plaintext plus a repeating key and produces the ciphertext bytes in both hex and Base64. Use this path when you are the sender.
- Select the encrypt mode on XOR Encryption Online.
- Type or paste the plaintext into the message field. The page encodes it as UTF-8 and the transform runs entirely in the browser, so the text never leaves your machine.
- Type the key into the key field. Treat the key as text: the literal characters you type are the UTF-8 bytes that get XORed, so key means the bytes 6B 65 79, not the bytes 6B 65 79 interpreted as a hex literal.
- Read the ciphertext from both output fields. The hex and Base64 strings encode the same bytes, so copy whichever one your recipient's system expects and tell them which representation you used.
- Send the ciphertext through whatever channel you would normally use, and deliver the key out of band. Repeat the key exactly, including case and any spaces, when you tell it to the recipient.
Decrypt a Message
Decryption reverses the XOR and validates that the recovered bytes form valid UTF-8. Use this path when you are the recipient.
- Switch the tool to decrypt mode.
- Pick the representation that matches the ciphertext you received, hex or Base64. Choose the wrong one and the parse step rejects the input before the XOR runs.
- Paste the ciphertext into the matching field. Whitespace inside the ciphertext is ignored, so line-wrapped hex and wrapped Base64 both work, but the strict parser will not fix a missing = padding or an odd number of hex digits.
- Enter the identical key text, character for character, including case and any spaces. The key wraps around the plaintext in the same repeating cycle that produced the ciphertext.
- Read the recovered plaintext. If the result is an error rather than text, the key or representation almost certainly does not match the sender's settings, so re-check both before treating the output as broken.
Key Rules That Decide Whether Decryption Works
Most "the recipient got garbage" problems trace back to a small set of conventions, all of which the tool holds fixed.
The key is text, not hex. The key field is interpreted as UTF-8 characters, then those characters are converted to bytes for the XOR. The word key becomes the three bytes 6B 65 79. If you type 6B6579 instead, the tool uses six bytes (the digits six, B, six, five, seven, nine) and the result will not match any tool that interprets the key as raw hex. Tools that work on UTF-16 code units, or that treat the key as a hexadecimal string, will also disagree. Aligning the convention matters more than the key length.
Bytes, not characters, are XORed. Plaintext and key are both UTF-8, so non-ASCII text and emoji consume several bytes each. Each emoji advances the key index by its UTF-8 byte length, which means a multi-byte character in the key eats more than one position per visible character. The XOR is byte-level, never grapheme-level, so results are reproducible across standards-compliant browsers, but the recipient must decode the output with the same UTF-8 byte convention to recover the original glyphs.
Whitespace is significant in the plaintext and the key, ignored in the ciphertext. A trailing space in the key changes the bytes after that point because it shifts the cycle, but a newline or space inside the hex or Base64 ciphertext is ignored for line wrapping. Whitespace is never trimmed automatically, and an empty plaintext or empty key is rejected outright.
The result has a hard size limit. Plaintext and key together are capped at 100,000 bytes to keep conversion, rendering, and copying responsive. Messages above that ceiling need to be split, encoded in chunks, or processed through a different tool entirely. The transform itself does not depend on the size, but the page enforces the limit to keep the browser responsive.
Successful UTF-8 decoding is not proof of a correct key. The decryption step runs fatal UTF-8 validation, so many wrong keys produce an error instead of a string of replacement characters. Some wrong byte sequences happen to form valid UTF-8 characters, especially with short ASCII messages, so a clean decode is necessary but not sufficient. Confirm meaningful plaintext through an independent channel before you trust it.
When Not to Use This Tool
XOR Encryption Online is reversible obfuscation, not authenticated encryption. The repeating key exposes statistical patterns, a known-plaintext fragment reveals the key bytes that produced it, short keys amplify both weaknesses, and an attacker can flip bits in the ciphertext without detection because there is no checksum, no authentication tag, no nonce, no salt, and no key-stretching routine. The tool has no key-management system either, so the security of the message reduces to the secrecy of the key string itself.
For that reason, do not use this page for passwords, payment details, private keys, personal records, or any information where confidentiality or integrity matters. Pick a reviewed authenticated cipher such as AES-GCM in a vetted application, or use a published library that handles keys and nonces for you. The warning is part of the tool's product behavior rather than a generic disclaimer: an encryption label must not imply protection that a repeating-key XOR transform cannot provide.
Treat the result as suitable for puzzles, classroom exercises, capture-the-flag challenges, and interoperability checks between systems that have already agreed on a byte convention. For a deeper look at the security trade-offs, the repeating-key reality check guide unpacks each weakness with a worked example and explains why the convenience of a single repeating key is also its main attack surface.