Repeating-key XOR is the symmetric operation that powers every basic XOR cipher online: the same single function encrypts and decrypts, you supply a key, and the message cycles against that key one byte at a time. XOR Encryption Online runs that operation in the browser on UTF-8 bytes and returns the result in two interchangeable representations — lowercase hexadecimal and standard padded Base64 — so you can paste whichever form the receiving system expects. Nothing leaves your device: the page does not upload the plaintext, the key, or the ciphertext, and an empty input or empty key is rejected outright. The convention is deliberately strict. Both plaintext and key are encoded as UTF-8, every plaintext byte is combined with the key byte at the same offset modulo the key length, and decryption applies the identical operation to parsed bytes before a fatal UTF-8 decode. Because XOR is self-inverse, switching the output between hex and Base64 changes only the representation of the bytes, not the underlying ciphertext.
How XOR Encryption Online transforms your text
An XOR cipher is bitwise exclusive OR applied to each byte: the result is 1 where the bits differ and 0 where they match. With a repeating key, position i of the plaintext is XORed with position i mod keyLength of the key. Run the same rule twice with the same key and you recover the original bytes — that is why XOR Encryption Online uses the same form for both directions. The page works entirely in your browser, uses TextEncoder to convert your text to UTF-8 bytes, and then performs the bitwise XOR operation on every byte before serializing.
| Representation | What you see | When to pick it |
|---|---|---|
| Hex | Two hexadecimal digits per byte, lowercase, contiguous | Inspecting individual bytes, comparing against a known vector, or matching a tool that emits hex |
| Base64 | Standard alphabet with correct padding | Pasting through form fields, email, chat, or any channel that mangles whitespace |
The page always shows both forms after a successful encrypt run, so you can copy whichever one fits the receiver. Switching between them never changes the underlying XOR ciphertext — only the bytes-to-text encoding.
Encrypt or decrypt text in three actions
- Select encrypt, type or paste the plaintext, and enter the exact repeating key. The key is treated as UTF-8 text, not as hexadecimal.
- Copy the primary hex or Base64 result and tell the recipient which representation you used. Either form decodes back to the same byte sequence.
- To recover text, the recipient selects decrypt, picks the matching format from the output dropdown, pastes the ciphertext, and enters the identical key — including case, spaces, and every Unicode character.
If the key, the ciphertext, or the byte encoding differ in any way, the recovered text will not match the original. That is the point of a strict convention: it removes ambiguity when you compare results with a command-line program, a programming library, or another online tool.
Hex versus Base64: pick the right output
Hex writes two hexadecimal digits per byte and is the easiest form to inspect by eye. Base64 represents the same bytes in a shorter, transport-friendly string that survives copy-paste through fields that strip whitespace or line breaks. The XOR Encryption Online interface surfaces both at once because the byte sequence is identical, so the choice is purely about what the next system expects.
| Property | Hex | Base64 |
|---|---|---|
| Length for N bytes | 2N characters | About 4N/3 characters plus padding |
| Allowed characters | 0–9 and a–f (whitespace ignored) | A–Z, a–z, 0–9, +, / and = padding |
| Whitespace tolerance | Ignored, useful for line wrapping | Not part of the alphabet, will fail strict parse |
| Typical use | Manual inspection, diffing test vectors | Pasting into chat, email, JSON payloads |
Decrypt mode parses the chosen representation strictly. Hex must contain complete byte pairs and only hexadecimal digits — whitespace is ignored for convenience, but stray non-hex characters raise an error. Base64 must use the standard alphabet with correct padding. The parsed bytes are XORed with the UTF-8 key and then decoded with fatal UTF-8 validation, which catches many wrong keys as a visible error rather than a string of replacement characters.
Why the same key looks different in other tools
Many XOR tools offer a "hex key" mode that interprets your input as raw bytes. XOR Encryption Online does not: the key field is treated as text. The key word key becomes the UTF-8 bytes 6B 65 79 — three bytes. If you instead type 6B6579 into the key field, the page uses the six visible characters in that string, not the three bytes they describe. This distinction is the most common reason results differ between tools or command-line programs.
Unicode text occupies more than one byte per visible character. A single emoji or a non-Latin script character may consume several key positions, so the key repeats at byte boundaries rather than at character boundaries. The implementation XORs bytes, not JavaScript UTF-16 code units and not user-perceived grapheme clusters — a fixed definition that keeps results reproducible across standards-compliant browsers.
A single byte worked through by hand
To see how the operation works on one byte, consider the letter A encrypted with the key letter k. The UTF-8 byte for A is 0x41 (binary 01000001). The UTF-8 byte for k is 0x6B (binary 01101011). XOR them bit by bit:
- Bit 7: 0 XOR 0 = 0
- Bit 6: 1 XOR 1 = 0
- Bit 5: 0 XOR 1 = 1
- Bit 4: 0 XOR 0 = 0
- Bit 3: 0 XOR 1 = 1
- Bit 2: 0 XOR 0 = 0
- Bit 1: 0 XOR 1 = 1
- Bit 0: 1 XOR 1 = 0
The result is 00101010, which is 0x2A in hexadecimal — the asterisk character. Run the same XOR a second time with k on 0x2A and you recover 0x41, which is A. That is the entire algorithm in one line: the same key reverses itself, which is why the cipher is symmetric.
Limits, errors, and what the page will reject
Input and key data are limited to 100,000 bytes to keep conversion, rendering, and copying responsive. Whitespace inside plaintext is significant — every space, tab, and newline becomes a byte in the ciphertext. Whitespace inside encoded ciphertext is ignored only for line wrapping; no other cleanup or guessing is performed. An empty input or an empty key returns an error immediately.
A wrong key usually produces invalid UTF-8, which the page reports as a visible decoding error instead of silently substituting the replacement character. This is intentional: it tells you the key is wrong or the ciphertext was corrupted. The trade-off is that some wrong byte sequences happen to form valid characters, especially with short ASCII messages. A successful UTF-8 decode therefore does not prove the key is correct. Confirm meaningful plaintext through an independent channel.
The page has no checksum, authentication tag, salt, nonce, password stretching, or key-management system. Hex output is lowercase and continuous, Base64 output uses canonical padding, and the parsed bytes are XORed with the UTF-8 key before the fatal UTF-8 decode.
When repeating-key XOR fits and when it does not
Repeating-key XOR is the right tool for reversible obfuscation, education, interoperability checks, and capture-the-flag exercises where the goal is to demonstrate an idea rather than to protect a secret. It is also useful as a sanity check: if two systems cannot agree on the same XOR output for the same input, the convention is different somewhere.
It is the wrong tool for anything that requires confidentiality or integrity. Key repetition exposes patterns. Known plaintext can recover key bytes directly. Short keys are especially weak, and an attacker can flip bits in the ciphertext to flip bits in the plaintext without detection. Do not use this page for passwords, personal records, payment details, private keys, or any information where a wrong key must be impossible. For real security, pick an authenticated encryption system that handles keys safely and resists tampering — see Is XOR Encryption Secure? A Repeating-Key Reality Check for the full breakdown.
For everyday text-shuffling between two people who already share a secret key, run XOR Encryption Online, agree on the key text and the output representation, encrypt once, share the ciphertext, and decrypt once on the other side. If the result fails, compare the exact characters in the key and confirm the transport did not trim or rewrite the ciphertext. The page treats the warning as part of the tool: a familiar encryption label must not imply protection that repeating-key XOR cannot provide.