b2KIT

XOR Cipher Tool

Apply XOR cipher operations with single-byte and multi-byte keys with hex input/output and key analysis.

Tested tool guide Tested browser tools Checked August 16, 2026

What XOR Cipher Tool does, with a checked example

This tool XORs input against a key you supply as text or hex, byte by byte, repeating a short key across a longer message the way a stream cipher does. You choose whether input and key are plain text or hex, and whether output comes back as hex or raw bytes. Its key-analysis mode works the other direction: given only ciphertext, it tries candidate single-byte keys and ranks the results by how closely the recovered text resembles readable content. The most common mistake is treating a matched key as proof the plaintext is correct - a wrong key can still produce readable-looking fragments by chance, especially on short ciphertexts.

Worked example

A concrete input and expected output from the current implementation.

Input

Plaintext: HELLO, Key (hex, single-byte): 2A, mode: encrypt, output as hex

Expected output

626f666665

Each ASCII byte of HELLO (48 45 4C 4C 4F) is XORed with the repeated key byte 2A, giving 62 6F 66 66 65; XORing that hex with the same key returns HELLO.

How the result is produced

1

Byte-by-byte XOR with key repetition

For multi-byte keys the tool cycles the key across the full input, XORing input byte i with key byte (i mod key length). A single-byte key is the special case where every byte is masked identically. XOR is its own inverse, so running the tool a second time with the same key and mode reversed returns the original input exactly.

2

Single-byte key recovery

When you provide ciphertext without a key, the analysis mode XORs it against all 256 possible single-byte values and scores each result by how much it resembles readable text - for example the proportion of printable ASCII characters - then surfaces the top-scoring candidates for you to inspect rather than declaring one definitive answer.

Good uses

  • recovering a string or flag hidden behind single-byte XOR obfuscation in a CTF challenge
  • decoding a short obfuscated string found in a config file or sample without writing a one-off script
  • checking your own encode/decode routine by XORing sample data against a known key and comparing the hex output

Limits and checks

  • XOR with a reused key is trivially broken by frequency analysis or known-plaintext attacks; this is obfuscation, not encryption, and should never protect real secrets
  • key-recovery scoring assumes the plaintext is readable, mostly-ASCII text; it will not reliably find the key for binary data, compressed content, or non-English text
  • hex input/output roughly doubles the character count of the underlying bytes, and an odd-length or malformed hex string will fail to parse or produce unexpected output

Common questions

Can I use this to encrypt sensitive data?

No. XOR with a repeating key is easily broken once an attacker has a moderate amount of ciphertext or can guess part of the plaintext. Use it for obfuscation, teaching, or CTF-style puzzles only, never to protect real secrets.

Why did key analysis return several candidate keys instead of one clear answer?

Short or ambiguous ciphertexts can score more than one candidate similarly, especially since single-byte keys only span 256 possibilities. Check the top few results yourself instead of trusting the single highest score, particularly on inputs under a few dozen bytes.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools