CruxDevCruxDev Tools Prompts
security Utility • Zero-Server Privacy • 100% Client-Side

XOR Cipher Encrypt / Decrypt

Apply XOR encryption with single-byte or multi-byte keys — supports hex, UTF-8, and Base64 key formats with brute-force analysis.

Overview

Applies a repeating-key XOR to your text and shows the result both as space-separated hexadecimal and as a printable rendering with \xNN escapes for non-printable bytes. Encoding is symmetric - running the same key over the output restores the original - and everything computes in the page as you type.

How It Works

Type your input and a key. Both outputs update live: the hex box shows every output byte in hexadecimal, and the text box shows printable characters directly with \xNN placeholders for bytes outside the printable range. With an empty key the tool passes the input through unchanged rather than erroring. Click either output to copy.

Step-by-Step Usage Guide

  1. Type the input text and the key. Outputs update on every keystroke.
  2. Read the hex output for the exact byte values - space-separated, two digits per byte.
  3. Use the text output only to eyeball the transformation; copy the hex for anything you will process further.
  4. To decode, paste the ciphertext as input and apply the same key - the identical operation reverses it.

Technical Specifications & Standards

The operation is byte-level: your input and key are encoded to UTF-8, and output byte i is input byte i XOR key byte (i mod key length) - the classic repeating-key construction, the binary descendant of the Vigenere cipher. XOR's involution property (x XOR k XOR k = x) is why the same operation decrypts: the tool has no separate mode because it needs none. Watch what the UTF-8 encoding means for multi-byte characters - an accented letter becomes two or more input bytes, each XORed independently, so the hex output reflects UTF-8 bytes, not characters. The printable rendering is for eyeballing only: bytes 32-126 display as characters, everything else as \xNN, and that representation is not a decodable encoding - use the hex output for anything mechanical. The security statement needs no hedging: repeating-key XOR is not encryption. It falls to frequency analysis (the key length leaks through periodicity, then each key byte is solvable against expected letter frequencies) and to known-plaintext instantly, since a guessed plaintext byte yields a key byte directly. Its honest uses are obfuscation, CTF fundamentals, and understanding the construction that stream ciphers build on with a keystream instead of a repeating key.

Targeted Use Cases

  • Learning or teaching why XOR is symmetric and how repeating keys leak structure.
  • Obfuscating strings in test fixtures where actual security is not the goal - such as hiding answers in a quiz app's data.
  • Working a CTF challenge that involves single-byte or repeating-key XOR, with instant visual feedback.
  • Inspecting how UTF-8 encoding makes multi-byte characters span several cipher operations.

Notes & Gotchas

  • Never use repeating-key XOR to protect anything real - it is broken by frequency analysis or one known plaintext byte per key position.
  • Copy the hex output, not the text rendering: the \xNN escapes are a display convention, not a decodable encoding.
  • Remember the key repeats over UTF-8 bytes, not characters; a key of length 3 over accented text operates on different byte positions than you might assume.
  • If you need actual encryption in the browser, use the site's AES tool or Web Crypto's AES-GCM directly - XOR here is for understanding, not protecting.

Frequently Asked Questions

How do I decrypt the output?

Apply the same operation again: paste the ciphertext and the same key, and XOR's involution property restores the original text. There is no separate decrypt mode because the transform is its own inverse.

Is XOR encryption secure?

No. Repeating-key XOR is broken by classical analysis - the key length leaks statistically, and each key byte then falls to frequency analysis. A single known plaintext byte reveals the key byte at that position. Use it for learning and obfuscation only.

Why does the text output contain \xNN sequences?

Bytes outside the printable ASCII range 32-126 cannot be displayed as characters, so the text view renders them as \xNN escapes. This view is for reading, not round-tripping - use the hexadecimal output when you need the exact bytes.

What happens with an empty key?

XOR with zero is the identity operation, so with no key the output equals the input and the tool passes it through rather than failing. Any non-empty key produces a real transformation.