An XOR cipher calculator applies the bitwise exclusive-or operation between every byte of a UTF-8 plaintext and the corresponding byte of a repeating key, turning each input into reversible ciphertext that can be shown as hex or Base64. Because XOR is its own inverse, applying the same key a second time restores the original bytes — provided both sides agree on the byte encoding, the repetition rule, and which representation was used. The XOR Encryption Online tool runs that exact transform inside your browser: plaintext and key are encoded as UTF-8, each plaintext byte is XORed with keyBytes[index modulo keyLength], and the result is serialized as lowercase hexadecimal and standard padded Base64. Nothing is uploaded, the key is treated as text rather than as raw hex bytes, and inputs are capped at 100,000 bytes to keep conversion and copying responsive. This page is built for educational ciphers, CTF puzzles, and interoperability checks between two scripts — not for protecting passwords, payment details, private keys, or any other sensitive information.
How a repeating-key XOR cipher works
XOR is a bitwise operation that returns 1 when the two input bits differ and 0 when they match. Applied to whole bytes, each bit of the plaintext is compared against the matching bit of the key, producing a new byte that has no obvious resemblance to either input. When the same key is XORed against the ciphertext a second time, the original bytes come back unchanged — that reversibility is what makes XOR a viable symmetric transform. In a repeating-key construction the key wraps around whenever the message is longer than the key, so position i of the plaintext is combined with position (i modulo keyLength) of the key.
Concretely, take the plaintext "ABC" encoded as the bytes 0x41 0x42 0x43 and the key "K" encoded as the single byte 0x4B. The transform runs as follows: 0x41 XOR 0x4B equals 0x0A, 0x42 XOR 0x4B equals 0x09, and 0x43 XOR 0x4B equals 0x08. Those three bytes are what the calculator emits. In hexadecimal they appear as the string "0a0908", two characters per byte, and in standard padded Base64 they appear as the four-character string "CgkI". Feeding "CgkI" back into decrypt mode with the identical key "K" returns "ABC". The same byte operation in both directions is what makes the cipher reversible and the output exchangeable between people, scripts, and command-line tools that follow the same convention.
Because XOR works on individual bits rather than on blocks or substitution tables, the output is always the same length as the input. Whitespace inside the plaintext is preserved and is therefore significant; whitespace inside an encoded ciphertext is ignored by the parser, which makes long hex strings easy to wrap across multiple lines without breaking decryption. The XOR operation itself is described in MDN's Bitwise XOR reference, and the byte-level encoding step uses the browser's built-in TextEncoder API, which keeps behavior consistent across standards-compliant browsers.
Encrypt text with the XOR cipher calculator
The encrypt path runs entirely in your browser and produces the same ciphertext in two representations at once. To get a clean, reproducible result, follow these steps:
- Open the XOR Encryption Online page and confirm that the mode is set to encrypt rather than decrypt.
- Type or paste the plaintext you want to transform into the message field; whitespace inside the message is preserved exactly.
- Type the repeating key into the key field exactly as you intend the recipient to type it — including every letter case and every space — because the key is treated as UTF-8 text.
- Run the local transform; the page displays the resulting bytes in both lowercase hex and standard padded Base64.
- Copy the representation your recipient expects and tell them which form you sent so they pick the matching option on their side.
The two outputs are not different ciphertexts. Hex and Base64 are just different ways of writing the same bytes: hex uses two hexadecimal digits per byte and is convenient for inspection and for tools that expect raw byte input, while Base64 is roughly a third shorter and survives cleanly through text fields, JSON payloads, and URLs that strip or rewrite non-printable characters. Switching between representations on the calculator never alters the XOR output itself — only the printable form changes.
Decrypt ciphertext back to plaintext
Decryption reuses the same XOR rule, which is what makes the cipher self-inverse. To recover the original text from a hex or Base64 message, follow these steps:
- Switch the page to decrypt mode.
- Pick the representation that matches what was sent — hex or Base64 — so the parser uses the right alphabet and padding rules.
- Paste the ciphertext into the input field. Whitespace and line breaks inside the ciphertext are ignored, so wrapped lines decode normally.
- Type the identical key, including capitalization and every space, then run the transform.
- Read the recovered plaintext. The page performs fatal UTF-8 validation on the result, so an incorrect key usually produces a visible error instead of silent replacement characters.
If decryption fails, compare the key character-by-character against what was sent and confirm the transport did not trim or re-encode the ciphertext. A successful UTF-8 decode is not a proof that the key is correct — some wrong byte sequences still form valid characters, especially with short ASCII messages where many wrong keys happen to land inside printable ranges. Confirm meaningful plaintext through an independent channel such as a phone call, a separate chat window, or a checksum that you trust.
Hex vs Base64: choosing the right output
Hex and Base64 are interchangeable representations of the same ciphertext bytes. The choice usually comes down to length, transport, and what the receiving system expects. The table below summarizes the practical differences when exchanging XOR ciphertext between two people or two scripts.
| Property | Hexadecimal | Base64 |
|---|---|---|
| Encoding per byte | 2 characters | about 1.33 characters |
| Character set | 0–9, a–f | A–Z, a–z, 0–9, +, / |
| Padding | None | = for non-aligned input |
| Typical size for 100 bytes | 200 characters | about 136 characters |
| Best for | Inspection, byte-level tools, debug logs | Text fields, JSON payloads, URLs, copy-paste |
| Whitespace handling | Ignored by the parser | Ignored by the parser |
Strict parsing in both directions is part of the contract. Hex must contain complete byte pairs and only hexadecimal digits, although whitespace is ignored for line wrapping. Base64 must use the standard alphabet with correct padding. The parsed bytes are XORed with the UTF-8 key, then decoded with fatal UTF-8 validation, so a malformed input raises a clear error rather than producing a silently corrupted plaintext. If a downstream tool expects Base64 but you only have a hex string, decode the hex to bytes first; if it expects hex but you have Base64, encode those bytes back as hex. The same ciphertext flows between the two representations without any change to the XOR output.
Key handling rules that change the result
The key is a plain text field, not a hexadecimal field. Typing the six visible characters "6B6579" uses six key positions — the UTF-8 bytes 0x36 0x42 0x36 0x35 0x37 0x39, one per character — and the result will not match a tool that interprets those characters as raw hex. To use the literal bytes 0x6B 0x65 0x79 as the key, type the three characters "key" instead. This distinction matters whenever you compare results with command-line programs or programming libraries: tools that treat the key as raw hex bytes, that operate on UTF-16 code units, or that work at the level of user-perceived grapheme clusters follow a different convention and will not agree with this page.
Both the plaintext and the key are encoded as UTF-8 before the XOR runs, so Unicode text is supported end to end. A visible character that occupies several UTF-8 bytes — an emoji, an accented Latin character, or a CJK glyph, for instance — consumes several key positions in a single character. The implementation XORs bytes, not JavaScript UTF-16 code units and not user-perceived grapheme clusters. That fixed definition is what makes mixed-language results reproducible across standards-compliant browsers.
An empty plaintext or an empty key is rejected outright. Input and key data are limited to 100,000 bytes to keep conversion, rendering, and copying responsive, so very large messages are better served by a streaming pipeline than by a single browser form. Whitespace inside the plaintext is preserved, and whitespace inside an encoded ciphertext is stripped by the parser so you can wrap long hex or Base64 strings without breaking decryption.
Limits, weak spots, and what this calculator cannot do
Repeating-key XOR is reversible obfuscation, not modern encryption. The tool exposes no authentication tag, no checksum, no salt, no nonce, no password stretching, and no key-management system. A short or predictable key exposes the message through frequency analysis and known-plaintext attacks; repetition reveals patterns that longer keys would hide; and any attacker who can modify the ciphertext can change the decrypted output without detection, because the transform has no integrity check. Treat the calculator as a teaching aid, a CTF helper, and an interoperability check — and stop there. A fuller breakdown of why repeating-key XOR fails as a security primitive lives in the repeating-key reality check; for anything sensitive, use a reviewed authenticated cipher such as AES-GCM with a vetted application that handles keys safely.
If you want to exchange a harmless puzzle with a friend, agree on the exact key text including case and spaces, encrypt the message, send one of the two representations, and have the recipient pick the matching option, paste the ciphertext, and enter the identical key. If the recovered text fails to read, the key characters or the transport encoding are the most likely culprits — recheck both before assuming the cipher itself is wrong. The XOR Encryption Online calculator is built for reversible obfuscation in education, interoperability, and capture-the-flag exercises; that label is descriptive, not a security claim.