Decrypt XOR ciphertext without the key: brute-force single-byte keys, break repeating-key XOR, crib-drag known plaintext. Text, hex or Base64, in-browser.
This free online XOR decoder does three jobs: it encrypts and decrypts data with a key you supply, it brute-forces short keys when you have none, and it breaks repeating-key XOR outright by recovering the key from the ciphertext alone. Input and output can each be plain text, hexadecimal, or Base64, and the key can be given as text, as hex bytes, or as a single byte. Everything runs in your browser — the brute-force search runs in a Web Worker so the interface stays responsive while it grinds — and no ciphertext is ever uploaded.
XOR is the exclusive-or operation applied byte by byte between plaintext and key. It is the simplest useful cipher and the one you meet constantly in CTF challenges, malware analysis, firmware inspection, and obfuscated JavaScript, because it is trivially implementable in a few instructions and leaves the data the same length. Its defining property is symmetry: plaintext XOR key = ciphertext and ciphertext XOR key = plaintext. There is no separate decryption routine — encoding and decoding are the same operation, which is why this tool has one Encrypt/Decrypt tab rather than two.
XOR compares two bits and returns 1 only when they differ:
| A | B | A XOR B |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
Applied to bytes, encrypting the character H (ASCII 0x48, binary 01001000) with the key byte 0x2A (00101010) gives 01100010 = 0x62. XOR the result with 0x2A again and you are back to 0x48. The two identities that make the whole tool possible are x XOR x = 0 and x XOR 0 = x.
Encrypting the string HELLO with the single-byte key 0x2A produces the hex 62 6f 66 66 65. With a multi-byte key such as KEY, the key repeats cyclically across the plaintext: byte 0 uses K, byte 1 uses E, byte 2 uses Y, byte 3 uses K again, and so on. That repetition is precisely the weakness the cryptanalysis tab exploits.
de ad be ef, or single-byte when the key is one value.Because XOR is its own inverse, the same operation covers both directions. If your output looks like noise, either the key is wrong or your input format is misidentified — a Base64 string parsed as text is a very common cause of “the decoder is broken”.
Single-byte XOR has only 256 possible keys, so exhaustive search is instant. Set Max Key Length to 1 byte and the tool tries every value from 0x00 to 0xFF, scores each candidate plaintext against English letter frequencies, and ranks the results. In practice the correct key is almost always the top hit for anything longer than a few dozen bytes of English text.
You can extend the search to 2, 3, or 4 bytes, and the tool shows the keyspace up front so you know what you are asking for:
| Max key length | Keys tried | Practicality |
|---|---|---|
| 1 byte | 256 | Instant |
| 2 bytes | 65,536 | Fast |
| 3 bytes | 16.7 million | Seconds to minutes |
| 4 bytes | 4.3 billion | Impractical — use the cryptanalysis tab instead |
The show only printable results filter hides candidates that decode to control characters, which typically removes well over 90% of the noise. Progress is reported live and the search can be cancelled at any point. When you spot the right plaintext, apply that key straight into the Encrypt/Decrypt tab with one click.
The important lesson from that table: brute force does not scale. Beyond about three bytes, guessing keys is the wrong approach entirely — and it is unnecessary, because repeating-key XOR can be broken without searching the keyspace at all.
This is the tab that matters for real challenges. Repeating-key XOR (sometimes called Vigenère XOR) falls to a two-stage attack that costs nothing like exhaustive search.
Assume a key length n, split the ciphertext into n columns by taking every n-th byte, and measure the Index of Coincidence within each column. If n is correct, every byte in a column was encrypted with the same key byte, so the column is a simple single-byte XOR of natural-language text and its IC lands near 0.067 (the value for English). If n is wrong, the column is effectively random and its IC sits near 0.038. The tool tests every length from 1 to 16 and ranks them by confidence.
Once the length is known, the problem collapses into n independent single-byte XOR problems — and each of those has only 256 possibilities. Solving them separately and reassembling gives the full key. A 16-byte key that would need 25616 guesses by brute force falls to 16 × 256 = 4,096 tests. The repeating-key solver does both steps in one action: leave the key length on auto and it detects the length, solves each column, and reports the recovered key in both text and hex, along with the decrypted plaintext. It needs at least 20 bytes of ciphertext; more is better, since the statistics get sharper with length.
When you can guess a fragment of the plaintext — a header like MZ, a word like flag{, or a common HTTP string — you can recover key material directly. Because plaintext XOR ciphertext = key, sliding your guessed crib along the ciphertext and XOR-ing at each offset produces a candidate key fragment at every position. The correct offset is the one where the recovered fragment is itself readable. The crib drag feature automates the slide and flags positions producing printable key material; the known-plaintext attack takes a matching plaintext and ciphertext pair and returns the key directly.
Candidate scoring uses a chi-squared comparison against expected letter frequencies. English is the default, but the tool also carries frequency tables for French, German, Spanish, Italian, and Portuguese — switch language if your target text is not English, or the top-ranked candidate will be wrong even when the attack itself succeeded.
A repeating-key XOR scheme leaks structure in several ways at once: identical plaintext blocks aligned to the key produce identical ciphertext blocks; the ciphertext preserves plaintext length exactly; and, as shown above, the key can be recovered from ciphertext alone with modest computation. XOR provides no authentication either, so an attacker who knows any plaintext can flip arbitrary bits in the corresponding ciphertext and control the decrypted result exactly.
The one XOR construction that is genuinely unbreakable is the one-time pad: a key that is truly random, at least as long as the message, and never reused. Reuse a one-time pad even once and the two ciphertexts XOR together to cancel the key, exposing the XOR of the two plaintexts. For anything real, use AES. Use XOR for CTFs, for obfuscation analysis, for understanding stream ciphers, and for reversing the lazy encoding layer someone wrapped around a payload.
Related tools: try the cipher identifier if you are not yet sure what scheme you are looking at, the one-time pad tool for the provably secure version of the same operation, the Caesar cipher decoder for shift ciphers, and the encoding chain analyzer when a payload has been wrapped in several layers of Base64, hex, and XOR together.
If the key is one byte, use the Brute Force tab — all 256 keys are tested instantly and ranked by how English-like the result is. If the key repeats over a longer ciphertext, use the repeating-key solver in the Cryptanalysis tab, which detects the key length by Index of Coincidence and then solves each key byte independently.
Yes. XOR is its own inverse, so applying the same key to ciphertext returns the plaintext. That is why the tool has a single Encrypt/Decrypt tab.
Input and output can each be plain text, hexadecimal, or Base64, chosen independently. Keys can be text, hex bytes, or a single byte value.
One-byte keys are instant (256 candidates). Two bytes is 65,536 and still fast. Three bytes is 16.7 million and takes seconds to minutes. Four bytes is 4.3 billion and is not a realistic approach — switch to the repeating-key solver, which does not search the keyspace at all.
Sliding a guessed plaintext fragment along the ciphertext and XOR-ing at every offset. Since plaintext XOR ciphertext equals key, the correct offset yields readable key material. It is the standard technique when you know something about the plaintext, such as a file signature or a flag prefix.
At least 20 bytes for the analysis to run, but statistical attacks improve sharply with length. A good rule of thumb is several times the key length per key byte — a 100-byte ciphertext with an 8-byte key gives roughly 12 bytes per column, which is usually enough to converge.
Usually the input format is wrong — hex parsed as text, or Base64 parsed as hex — or the key format does not match how the key was originally supplied. Check the printable indicator: if the output is non-printable across the board, the key or format is off.
No, not with a short or repeating key. It has no authentication and its key is recoverable from ciphertext alone. Only the one-time pad variant — truly random key, at least as long as the message, never reused — is secure, and it is impractical for most uses. For real encryption use AES.
No. Encryption, brute force, frequency analysis, key-length detection, and crib dragging all execute locally in JavaScript and a Web Worker. Your ciphertext is never transmitted.
Yes — the tool can encode your current input and settings into a permalink, so you can send a colleague or teammate the exact state you are looking at.
Not sure which cipher you have? Use the Cipher Identifier to auto-detect cipher types from unknown ciphertext using frequency analysis and Index of Coincidence.
XOR encryption is a fundamental cryptographic technique based on the exclusive OR (XOR) bitwise operation. It operates on the principle that combining data with a key using XOR produces encrypted output, and applying XOR again with the same key recovers the original data.
| Input A | Input B | A XOR B |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
The key insight: XOR outputs 1 only when inputs differ, and 0 when they are the same.
XOR encryption is excellent for learning cryptographic concepts. Its simplicity makes it ideal for understanding bitwise operations, symmetric encryption, and cryptanalysis techniques.
XOR ciphers are common in CTF cybersecurity challenges. This tool provides cryptanalysis features (brute force, key length detection, known-plaintext attack) needed to solve these puzzles.
Many malware samples use XOR encryption to obfuscate strings, URLs, and payloads. Security researchers use XOR decoders to reveal hidden content.
XOR can scramble data to prevent casual observation (not security-focused use cases).
Important: Basic XOR encryption with short or reused keys is NOT secure. It is vulnerable to frequency analysis, known-plaintext attacks, and brute force. Only use this tool for learning, CTF challenges, and analysis - never for protecting real sensitive data. Use AES-256 or ChaCha20 for actual security needs.
This XOR decoder gives you three escalating ways to recover plaintext when you do not have the key.
When the ciphertext was XORed against a single repeating byte, there are only 256 possible keys. The tool tries all of them, decodes each candidate, and ranks the results by an embedded English-frequency score so the readable plaintext floats to the top. This is the fastest way to decode classic single-byte XOR obfuscation (very common in malware string hiding and beginner CTF challenges).
Longer keys cannot be brute forced exhaustively — a 6-byte key already has 281 trillion possibilities. Instead the tool uses the classic break-repeating-key-XOR attack:
The result panel shows the recovered key in both text and hex with copy buttons, plus the full decrypted plaintext — one click applies it in the Encrypt/Decrypt tab.
If you know a word or fragment that appears somewhere in the plaintext — a "crib" such as the , GET /, or flag{ — you can slide it across every offset of the ciphertext. At each position, crib XOR ciphertext reveals a candidate key fragment. Printable fragments are highlighted because they are the likely real key bytes, letting you reconstruct the key piece by piece even when frequency analysis alone is ambiguous.
XOR is its own inverse: (plaintext XOR key) XOR key = plaintext. Because the same operation encrypts and decrypts, and because short or reused keys leak statistical structure, XOR ciphertext is highly recoverable through frequency analysis, brute force, and known-plaintext attacks. This is exactly why XOR alone is unsuitable for real security — use AES-256 or ChaCha20 for that — but it is also why XOR is a perfect teaching ground for cryptanalysis.
Privacy: every operation here — encrypt, decrypt, brute force, repeating-key recovery, and crib-drag — runs entirely in your browser. No ciphertext, key, or plaintext is ever uploaded.
XOR (Exclusive OR) cipher is a simple encryption method that uses the XOR bitwise operation. XOR returns 1 when inputs differ and 0 when they match: 0 XOR 0 = 0, 1 XOR 1 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1. Encryption process: (1) Convert plaintext to binary, (2) Convert key to binary, (3) XOR each bit of plaintext with corresponding key bit, (4) Result is ciphertext. Key property: XOR is self-inverse: plaintext XOR key = ciphertext, ciphertext XOR key = plaintext. Example: Text "A" (01000001) XOR Key "K" (01001011) = Ciphertext (00001010). XOR cipher is symmetric - same key encrypts and decrypts. While simple and fast, XOR cipher provides ZERO security with predictable keys. It's primarily educational, showing fundamental concepts of stream ciphers and one-time pads.
XOR encryption is a symmetric encryption method that uses the XOR (exclusive OR) bitwise operation to combine plaintext with a key. Each bit of the input is compared with the corresponding bit of the key: if the bits are different, the result is 1; if they are the same, the result is 0. The key property of XOR encryption is that it is self-reversing: applying XOR with the same key twice returns the original data (plaintext XOR key = ciphertext, ciphertext XOR key = plaintext). This makes XOR ideal as a building block in cryptographic systems like AES and stream ciphers, though single-key XOR encryption alone is not secure for sensitive data.
No! XOR cipher is NOT secure for protecting sensitive data unless used correctly as a one-time pad. Security weaknesses: (1) Repeating keys - If key is shorter than message and repeats, patterns emerge. Easily broken with frequency analysis. (2) Known plaintext - If attacker knows any plaintext, they can recover the key: plaintext XOR ciphertext = key. (3) Pattern preservation - Spaces, common words create recognizable patterns. (4) Key reuse - Using same key twice is catastrophic: ciphertext1 XOR ciphertext2 = plaintext1 XOR plaintext2 (key cancels out!). Only secure use: One-Time Pad - Key is truly random, same length as message, used only once, kept secret. This provides perfect security but is impractical (key management nightmare). Modern alternatives: Use AES-256 for encryption, ChaCha20 for stream ciphers, TLS/SSL for communications. Never use simple XOR for production security. Learn from it, but don't deploy it.
XOR encryption works by applying the exclusive OR operation bit-by-bit between your plaintext and a key. For example, to encrypt "A" (binary: 01000001) with key "K" (binary: 01001011), you XOR each bit: 01000001 XOR 01001011 = 00001010. The result is your ciphertext. To decrypt, simply XOR the ciphertext with the same key: 00001010 XOR 01001011 = 01000001 (back to "A"). For longer messages, the key repeats cyclically over the plaintext. This tool supports text, hexadecimal, and Base64 input/output formats, plus single-byte and multi-byte keys for flexible XOR encryption and decryption.
XOR ciphers vary by key length and complexity: Single-byte XOR - One byte key (0-255), repeats for entire message, only 256 possible keys, trivial to brute force (try all 256 keys, look for readable text), vulnerable to frequency analysis, common in CTF challenges and malware obfuscation. Multi-byte XOR - Multiple byte key (e.g., "SECRET"), key repeats when shorter than message, much larger keyspace (256^n for n-byte key), still vulnerable to: Known plaintext attacks, Key length detection (Kasiski examination, Index of Coincidence), Frequency analysis once key length known. Example attack on multi-byte XOR: (1) Detect key length using statistical methods, (2) Split ciphertext into blocks of key length, (3) Each block position uses same key byte, (4) Apply single-byte XOR cracking to each position. Real-world use: Multi-byte XOR with random keys approximates stream ciphers, used in protocols like WEP (broken), RC4 (deprecated). Modern cryptography uses complex stream ciphers, not simple XOR.
Basic XOR encryption with short or reused keys is NOT secure and should never be used for protecting sensitive data. It is vulnerable to: (1) Frequency analysis - encrypted data retains statistical patterns, (2) Known-plaintext attacks - if any plaintext is known, the key is revealed, (3) Brute force - single-byte XOR has only 256 possible keys. However, XOR becomes theoretically unbreakable as a One-Time Pad when the key is truly random, as long as the message, and never reused. Modern encryption (AES-256, ChaCha20) uses XOR as one component among many secure operations. Use this tool for learning, CTF challenges, and malware analysis - not for real security.
XOR cipher is vulnerable to multiple attacks: Method 1: Brute Force (single-byte) - Try all 256 possible key bytes, check results for readable text, typically takes <1 second. Method 2: Frequency Analysis - English text has predictable letter frequencies (E, T, A, O most common), XOR preserves relative frequencies, XOR ciphertext with common chars (" ", "e", "t"), look for patterns. Method 3: Known Plaintext - If you know any plaintext fragment: plaintext XOR ciphertext = key, apply discovered key to rest of message. Method 4: Crib Dragging (multi-byte keys) - Guess common words ("the", "and", "password"), XOR guess with ciphertext at different positions, if guess correct, reveals key bytes. Method 5: Key Length Detection - For repeating keys: Kasiski examination (find repeated sequences), Index of Coincidence (statistical measure), Autocorrelation (cryptanalysis technique). Automated tools: xortool (Python), XORBruteForcer, CyberChef. This tool includes brute force functionality for educational purposes. Real malware often uses XOR obfuscation, making these techniques valuable for security analysts.
A one-time pad (OTP) is the only provably unbreakable encryption method, using XOR with specific requirements: Requirements for OTP: (1) Key is truly random - Generated with hardware RNG or quantum sources, not pseudo-random. (2) Key equals message length - No key reuse across multiple bits. (3) Key used only once - Never reuse any key bits for any reason. (4) Key kept secret - Both sender and receiver have key, never transmitted. Why it's unbreakable: Without the key, any plaintext of same length is equally likely, attacker cannot determine correct plaintext from ciphertext alone, no amount of computing power helps (even quantum computers). Practical problems: Key distribution (how to securely share random key?), Key storage (need secure storage for huge keys), Key management (one key per message - impractical), No authentication (doesn't prevent tampering). Real-world use: Intelligence agencies for highest-security communications, "Moscow-Washington hotline", Diplomatic communications. Why not used everywhere: Impractical key management. Modern ciphers (AES) provide "computational security" - secure until computers become much more powerful. OTP provides "perfect security" but is practically unusable for most applications.
XOR is fundamental to cryptography despite simple XOR cipher being insecure: XOR in secure algorithms: (1) Block ciphers - AES internally uses XOR operations extensively, key mixing and round operations rely on XOR, secure because of complex transformations and key schedules. (2) Stream ciphers - ChaCha20, Salsa20 XOR keystream with plaintext, keystream generated by complex algorithms, not simple repeating key. (3) Hashing - SHA-256 uses XOR in compression functions, HMAC uses XOR for key padding. (4) Error detection - CRC, checksums use XOR, Parity bits use XOR operations. (5) Differential cryptanalysis - XOR used to analyze cipher security. Why XOR is useful: Hardware efficient (simple logic gates), Fast computation (single CPU instruction), Self-inverse (same operation encrypts/decrypts), Doesn't leak information (output bit depends equally on both inputs). The key insight: XOR itself isn't weak - using XOR with predictable/repeating keys is weak. Modern crypto uses XOR with unpredictable keystreams from secure PRNGs. Simple XOR cipher is like using addition for encryption - the operation is fine, but the implementation is naive. Learn XOR principles, then understand why modern ciphers layer complexity on top.
Malware commonly uses XOR for obfuscation to evade detection: Why malware uses XOR: (1) Simple implementation - Easy to code in any language, minimal code footprint. (2) Fast execution - Nearly instant encryption/decryption. (3) Evades signature detection - Static analysis can't see plaintext strings, antivirus signatures won't match. (4) Reversible - Malware can decrypt itself at runtime. Common patterns: Single-byte XOR with hardcoded key (0x42, 0x55, 0xFF common), Multi-byte XOR with "password" string, XOR with rotating counter (key = byte_position XOR 0x42), XOR encoded shellcode or configuration data. Detection techniques: Entropy analysis (XOR text has medium entropy), Strings analysis (look for XOR artifacts), Brute force decryption (try all single-byte keys), Yara rules for XOR patterns, Behavioral analysis (watch for memory decryption). Example malware: WannaCry used XOR for configuration, Emotikon uses XOR encoded strings, Many ransomware samples XOR encrypt command & control URLs. For security analysts: This tool helps analyze suspicious files, understand obfuscation techniques, practice malware reverse engineering, extract hidden strings from samples. Remember: analyzing malware requires safe environments (VMs, isolated networks).
Paste your ciphertext (hex is recommended for binary data) into the Brute Force tab and start the search. For single-byte XOR there are only 256 possible keys, so the tool tries every one, decodes the result, and ranks candidates by an English-frequency score — the readable plaintext rises to the top. Click any result to apply that key in the Encrypt/Decrypt tab. For longer keys, use the "Break Repeating-Key XOR" solver in the Cryptanalysis tab instead of exhaustive brute force.
You have three options depending on the key. (1) Single-byte XOR: use Brute Force to try all 256 keys and pick the readable result. (2) Multi-byte / repeating key: use "Break Repeating-Key XOR" in the Cryptanalysis tab, which detects the key length and solves the key column-by-column automatically. (3) If you know any part of the plaintext, use Crib-Drag to slide that known substring across the ciphertext and recover key fragments. All three run entirely in your browser.
Open the Cryptanalysis tab and use the "Break Repeating-Key XOR" solver. It first estimates the key length (using the Index of Coincidence and by scoring candidate decryptions), then transposes the ciphertext into columns where every byte shares the same key position. Each column is solved as a single-byte XOR by trying all 256 values and keeping the most English-like result. The per-column key bytes are reassembled into the full key, which is shown in text and hex along with the decrypted plaintext. You can also force a specific key length if you already know it.
Crib-dragging is a known-plaintext technique: if you know a short string that appears somewhere in the message (a "crib" like "the ", "GET /", or "flag{"), you slide it across every byte offset of the ciphertext. At each position, XORing the crib with the ciphertext bytes reveals a candidate fragment of the key. Fragments that come out as readable, printable text are almost certainly the real key bytes at that offset, letting you reconstruct the key piece by piece. The Crib-Drag panel in the Cryptanalysis tab does this automatically and highlights the printable fragments first.
Yes. The Encrypt/Decrypt tab accepts text or hex keys of any length and applies them cyclically. If you do not know the key, the "Break Repeating-Key XOR" solver recovers multi-byte keys automatically by detecting the key length and solving each key position from frequency analysis, and Crib-Drag recovers key fragments from any known plaintext. Recovered keys can be applied with one click and copied as text or hex.