b2KIT

XOR Cipher Tool

Apply XOR cipher to text or binary data with a repeating key. Visualize bitwise operations step by step.

Tested tool guide Tested browser tools Checked August 16, 2026

What XOR Cipher Tool does, with a checked example

This tool takes a plaintext (or hex/binary) input and a key, repeats the key to match the input length, and XORs each byte pair, showing the binary of each byte alongside the result as it goes. Because XOR is its own inverse, running the same key over the ciphertext output reproduces the original input. The most common surprise: the result is rarely printable text, since XOR-ing two ASCII bytes usually lands outside the printable range, so the tool shows it as hex or lets you view raw bytes rather than a garbled string.

Worked example

A concrete input and expected output from the current implementation.

Input

text: "AB" (typed as text, not hex; ASCII bytes 0x41 0x42), key: "A"

Expected output

hex: 00 03

The key "A" (0x41) repeats for each input byte: 'A' (0x41) XOR 'A' (0x41) = 0x00, and 'B' (0x42) XOR 'A' (0x41) = 0x03.

How the result is produced

1

Key repetition and byte alignment

The key is repeated (not padded with zeros) until it matches the length of the input, then each input byte is XORed with the corresponding key byte at the same offset, wrapping the key index with modulo. Feeding a key longer than the input just uses its leading bytes once.

2

Step-by-step bitwise view

For each byte pair, the tool lists both operands in 8-bit binary, aligns them, and XORs bit by bit, so a 1 appears in the result only where the two input bits differ. This is meant to make the mechanics visible, not to speed up processing large inputs.

Good uses

  • Decoding a simple XOR-obfuscated string found in a CTF challenge or malware sample once you have or are brute-forcing the key
  • Demonstrating to students why single-byte or short repeating-key XOR is weak by showing the recovered plaintext pattern when the key is shorter than the message
  • Manually verifying a stream-cipher keystream XOR step while debugging custom encoding code without writing a throwaway script

Limits and checks

  • Repeating-key XOR is not secure encryption - if the key is shorter than the message and the message has any redundancy, it is breakable by frequency or Kasiski-style analysis; this tool does not warn you if you use it for actual data protection
  • Output bytes are frequently non-printable, so what you see is a hex or escaped representation of the ciphertext, not the literal bytes - copying the displayed text is not the same as copying the raw binary
  • If input and key are entered as text, character encoding (ASCII vs UTF-8 multi-byte) affects which bytes actually get XORed, so non-ASCII characters in either field can produce results that don't match a byte-by-byte hand calculation done assuming plain ASCII

Common questions

Can I use this to XOR two binary files together, not just text?

Only if the tool's input mode accepts hex or base64 for both the data and the key fields - check which input formats are offered before assuming raw file bytes are supported. If it only takes typed text, you'd need to convert file bytes to hex first.

Is XOR with a repeating key the same as a one-time pad?

No. A one-time pad requires a truly random key at least as long as the message, used exactly once. A repeating key is shorter than the message and reused, which reintroduces the plaintext's statistical patterns into the ciphertext and makes it crackable.

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