Free online deobfuscator for Base64, hex, XOR, ROT and URL-encoded strings. Auto-detects the encoding, brute-forces XOR keys, decodes PowerShell payloads.
This deobfuscator takes an encoded, packed or scrambled string and turns it back into readable text so you can see what it actually does. It is built for defensive work — incident response, phishing triage, log review and CTF challenges — where you have pulled a suspicious blob out of an email attachment, a scheduled task, a registry Run key or a web server log and need to know what it says before you decide how to respond. Everything runs client-side in your browser using standard JavaScript decoding routines: the sample you paste is never uploaded to a server, which matters when the artefact is evidence from a live incident.
The tool is a decoder, not a sandbox. It never executes the input. It reverses the layers of encoding that attackers stack on top of a payload to defeat signature matching, and it stops there — what you get back is text you can read, grep and hand to your ticketing system. If the decoded result is itself another encoded layer, you can feed it straight back in and keep peeling.
The tool supports a specific, finite set of encodings. Knowing exactly what is covered saves you from assuming a clean output means “nothing found”:
- and _ substituted for + and /), with automatic padding repair when the trailing = characters have been stripped.powershell.exe -EncodedCommand. Ordinary Base64 decoders return this as text riddled with null bytes; this decoder handles the UTF-16LE code path separately and gives you clean PowerShell source. A one-click PowerShell Encoding preset selects it.0x prefixes and other separators, which are stripped before decoding. Common in shellcode blobs and in char-array droppers.%41%42 style escaping used heavily in exploit URLs and web shell parameters.What it does not do is equally important. It is not a JavaScript AST deobfuscator: it will not rename mangled identifiers, evaluate packer bootstrap code, unroll eval chains automatically or reconstruct control flow from a flattened switch. It will decode the Base64, hex and XOR blobs that such packers embed, which is usually where the interesting strings live. It also does not unpack PE files, dump memory or emulate a script host.
Set the technique selector to Auto and the deobfuscator attempts every supported decoder and scores each result instead of guessing once. Two signals drive the ranking. The first is Shannon entropy, calculated over the decoded bytes. Meaningful English text and source code sit in a low band, roughly 3.5 to 4.5 bits per character; compressed or encrypted data pushes toward 7.5 to 8.0. A decode that lowers entropy is almost always the right one. The second is a readability heuristic, which weights the output by English letter frequency (e, t, a, o, i, n and the space character carry the most weight), adds a bonus for common tokens such as the, function, var, script and http, and subtracts a penalty for every non-printable byte. The combined score is why a correct single-byte XOR key floats to the top of 256 candidates without you reading them all.
A typical maldoc chain is Base64 wrapping a UTF-16LE PowerShell command, which itself contains a hex-encoded URL. Peeling it looks like this:
-enc or -EncodedCommand into the input box and click the PowerShell Encoding preset. The Base64 (UTF-16LE) result comes back as readable PowerShell rather than P.o.w.e.r.S.h.e.l.l.$u = [System.Text.Encoding]::ASCII.GetString([byte[]]-split('68 74 74 70 ...')). Copy the hex run, switch the technique to Hex, and decode it to reveal the staging URL.Rather than shuttling text between tabs, use Chain. Each decode result has a Chain button that pushes the output onto a visible stack of steps, so you end up with an auditable record of exactly which transformations produced the final plaintext — useful when you have to write the finding up later.
Because decoding happens locally, nothing leaves your machine — but the decoded output is still attacker-controlled text. Never paste a decoded command into a terminal to “see what happens”. Extract indicators instead: domains, IP addresses, file paths, mutex names and scheduled task names. Defang every URL and IP before sharing. If the decode yields a file signature rather than text, check the leading bytes with the file magic number checker, and inspect the raw bytes in the hex editor. For simple Base64 work outside an investigation, the Base64 encoder and decoder is the lighter tool.
A deobfuscator reverses the transformations an author applied to hide the meaning of code or data. In malware analysis that usually means undoing encoding layers — Base64, hex, XOR, ROT, percent-encoding — so that the underlying commands, URLs and strings become readable again.
Yes. It is free to use, requires no account, and imposes no per-day decode limit.
All decoding runs in your browser with client-side JavaScript, so the sample is never transmitted or stored on a server. The tool also never executes the input — it only decodes it. That said, treat the decoded output as hostile text and do not run it.
It decodes the encoded payloads inside obfuscated JavaScript — Base64 blobs, hex-escaped strings, percent-encoded fragments and XOR-masked data — which is where the meaningful strings usually hide. It does not perform AST-level deobfuscation such as identifier renaming, control-flow unflattening or automatic evaluation of packer bootstraps.
Paste the Base64 blob and choose the PowerShell Encoding preset. PowerShell encodes the command as UTF-16LE before Base64, so a standard Base64 decoder interleaves null bytes into the output; this tool decodes the UTF-16LE layer correctly and returns clean script text.
Leave the key field empty. The tool tries all 256 single-byte keys, scores each candidate plaintext using entropy and English readability, and shows you the strongest results first. Multi-byte and rolling keys are outside its scope.
Entropy measures how random the decoded bytes look, in bits per character. Readable text and source code typically land between 3.5 and 4.5; compressed, encrypted or still-encoded data trends toward 8.0. A decode that drops entropy sharply is almost certainly correct.
Yes. Click Chain on any result to push it forward as the input to the next step. The chain stays visible so you can see the full sequence of transformations and remove a step if you took a wrong turn.
Yes. URL-safe characters are normalised back to the standard alphabet and missing = padding is reconstructed before decoding, so truncated blobs from URLs and JWT-style fragments still decode.
No. There is no server round trip for decoding, no upload of pasted content, and no retention of samples.
Malware deobfuscation is the process of reversing the obfuscation techniques that malware authors use to hide the true functionality of their code. Obfuscation makes malware harder to analyze, evade antivirus detection, and slow down incident response. Deobfuscation restores the original code logic, revealing the malware's capabilities, command-and-control infrastructure, and payload delivery mechanisms.
Modern malware routinely employs multiple layers of obfuscation — string encoding, control flow manipulation, code packing, and encryption — requiring analysts to systematically peel back each layer to understand the threat.
| Technique | How It Works | Deobfuscation Approach |
|---|---|---|
| Base64 encoding | Strings encoded as Base64 | Decode Base64 segments |
| XOR encryption | Data XORed with a key | Identify key through known-plaintext or brute force |
| String concatenation | Strings built character by character at runtime | Execute or trace to reveal full strings |
| Dead code insertion | Useless instructions added to confuse analysis | Remove non-functional code paths |
| Control flow flattening | Restructure code into a switch-based dispatcher | Reconstruct original control flow |
| Packing | Compress/encrypt entire binary, decrypt at runtime | Unpack in debugger or emulator |
| Variable renaming | Meaningful names replaced with random strings | Rename based on function analysis |
| Anti-debugging | Detect debuggers and alter behavior | Bypass detection checks |
Malware obfuscation is the technique of disguising malicious code to evade detection by security tools and analysts. Why attackers use it: (1) Bypass antivirus - Obfuscated code does not match known malware signatures, (2) Hide intent - Makes it harder for analysts to understand what the malware does, (3) Evade static analysis - Automated tools cannot easily scan obfuscated code, (4) Delay response - Forces security teams to spend time decoding instead of responding. Common obfuscation methods: Base64 encoding (PowerShell, scripts), XOR encryption (packers, loaders), String concatenation (JavaScript), Dead code injection (bloat), Control flow flattening (assembly reordering). Real-world examples: PowerShell downloaders encode commands in Base64, Emotet uses XOR to hide C2 domains, JavaScript miners obfuscate with eval() chains. Deobfuscation is critical for incident response and threat intelligence - you cannot defend against what you do not understand.
Auto-detection mode systematically tries multiple deobfuscation techniques and ranks results by readability and entropy scoring. Process: (1) Base64 detection - Tries standard and URL-safe Base64 decoding, (2) Hex detection - Attempts hexadecimal to ASCII conversion, (3) URL decoding - Tests percent-encoded strings, (4) ROT cipher - Tests ROT1, ROT3, ROT7, ROT13, ROT25, (5) XOR brute force - Tests all 256 single-byte XOR keys, (6) Scoring - Each result gets readability score based on English letter frequency and common words. Best match criteria: Highest score wins, visible at top with green highlight, considers printable characters and entropy levels. Use cases: Unknown malware samples, multi-encoded strings, quick triage during incident response. Limitations: Does not detect custom encodings, complex multi-byte XOR, compression (gzip, deflate), or polymorphic code. For those, use manual chaining with specific keys.
XOR brute force systematically tests all 256 possible single-byte XOR keys (0x00 to 0xFF) to decode obfuscated data. How it works: For each key byte K: (1) XOR every byte of input with K, (2) Score result based on printable character ratio, (3) Apply English frequency analysis, (4) Check for common words (script, http, function, var), (5) Rank by total score. When to use: Malware network indicators (C2 domains, IPs) often XOR-encoded with single byte, Shellcode obfuscation in exploits, Ransomware config files hiding keys/domains, CTF challenges and malware reversing puzzles. How to identify XOR encoding: Data looks random but has consistent byte distribution, Known plaintext attacks - if you know part of decoded string, Entropy not quite random. Real example: Emotet malware XORs C2 server list with 0x42, one click brute force reveals all IPs. Multi-byte XOR: For keys longer than 1 byte, auto-detection will not work.
Malware often uses multiple layers of encoding to evade detection. Chaining allows you to decode layer by layer. Process: (1) Run auto-detect or specific technique on input, (2) Click Chain button on promising result to use it as input for next step, (3) Select next technique (e.g., Base64 then XOR), (4) Repeat until readable plaintext emerges. Common chain patterns: PowerShell: Base64 to URL decode to Base64 again, JavaScript: URL decode to Base64 to eval code, Shellcode: Hex to XOR to assembly, Custom packers: Base64 to gzip to XOR to PE file. Example real-world chain: Obfuscated PowerShell downloader uses Base64 (outer layer) then XOR (middle layer) then Base64 again (inner C2 URL). Without chaining, you would miss the final payload. Chain view shows all steps with inputs and outputs so you can track your deobfuscation progress and share findings with team.
Readability score and entropy help identify successful deobfuscation automatically. Readability Score: Measures how much decoded output looks like real text. Based on English letter frequency (e, t, a, o, i most common), Common word detection (the, and, http, script, function), Printable character ratio (ASCII 32-126), Whitespace and punctuation patterns. High score (100+) indicates likely successful decode, low score (0-30) means still obfuscated or wrong key. Entropy: Measures randomness of data. Low entropy (2-4) = Repeated patterns, plain text, High entropy (7-8) = Random, compressed, or encrypted. Ideal for malware strings: entropy around 4-5 after deobfuscation. Use together: High readability + Medium entropy = Success, Low readability + High entropy = Still encrypted, High readability + Low entropy = Possible false positive (repeated chars). Example: XOR with correct key drops entropy from 7.2 to 4.8 and readability jumps from 5 to 250.
Identifying the encoding technique requires pattern recognition and statistical analysis. Visual indicators: Base64: A-Z, a-z, 0-9, +, /, = padding, length divisible by 4, often ends with = or ==. Hex: Only 0-9 and A-F characters, even length, pairs represent bytes. URL encoding: Percent signs followed by hex (%20, %3A, %2F), mixed with regular characters. ROT13/Caesar: Looks like scrambled text, letter frequency still visible, preserves case and spacing. XOR: Completely random looking, may have repeating patterns if key is short. Statistical analysis: Base64: Entropy around 6.0, 75% efficiency (3 bytes to 4 chars). Hex: Entropy around 4.0, 50% efficiency (1 byte to 2 chars). Encrypted/XOR: High entropy (7-8), appears random. Compressed: Very high entropy (7.5-8), no patterns. Quick test: Try auto-detect mode first, Check length (Base64 increases by 33%, Hex doubles), Look for padding or special chars, Consider context (PowerShell = likely Base64, Network traffic = maybe Hex).
Finding malicious code during deobfuscation requires careful handling and proper incident response. Immediate actions: (1) DO NOT execute the code - even in a VM without proper isolation. (2) Document everything: Take screenshots, save all deobfuscation steps, record timestamps, note file hashes. (3) Isolate the system: Disconnect from network if malware is active, Preserve memory and disk state, Do not shut down immediately (loses RAM evidence). (4) Analyze safely: Use dedicated malware analysis VM, Disable network or use isolated test network, Take snapshots before any execution. Security team notifications: Alert your SOC/IR team immediately, Provide IOCs: IPs, domains, file hashes, URLs, Share deobfuscation chain for their analysis. Threat intelligence: Check if already known (VirusTotal, AlienVault, MISP), Submit IOCs to sharing platforms, Document TTPs for future detection. Legal considerations: Preserve evidence for forensics, Follow data breach notification laws if applicable, Coordinate with legal team before public disclosure. Remember: This tool is for ANALYSIS only, not for creating or modifying malware.
No single tool can detect all obfuscation techniques. This tool covers common methods but has limitations. Supported techniques: Base64 encoding (standard and URL-safe), Hexadecimal encoding, URL/percent encoding, ROT-N ciphers (1-25), Single-byte XOR (brute force all 256 keys), Multi-byte XOR (if you know the key). Limitations and what we DO NOT support: (1) Compression: GZIP, Deflate, LZMA, Bzip2 - requires external tools. (2) Strong encryption: AES, RSA, 3DES - cannot be brute forced. (3) Custom algorithms: Proprietary encoding schemes unique to specific malware. (4) Polymorphic code: Self-modifying code that changes each execution. (5) Binary packers: UPX, ASPack, Themida - needs specialized unpackers. (6) Steganography: Data hidden in images, audio files. (7) Complex multi-byte XOR: Without key length detection. Recommended workflow: Start with this tool for initial triage, Use IDA Pro, Ghidra for binary analysis, Use sandbox environments (Any.run, Joe Sandbox) for dynamic analysis, Combine with YARA rules and signature detection. Think of this as first-stage triage, not complete analysis suite.
Sophisticated malware uses layered obfuscation to maximize evasion and slow down analysis. Common layering strategies: (1) Onion model: Each layer wraps the previous, Example: Base64(XOR(Hex(payload))), Must decode in reverse order applied. (2) Stage-based: Different layers for different stages, Stage 1: URL decode (initial dropper), Stage 2: Base64 (downloaded payload), Stage 3: XOR (final shellcode). (3) Mixed encoding: Combine encoding with encryption, Example: Base64(AES(payload, key)), Key itself might be XOR-encoded. Real-world examples: Emotet: Base64 outer layer, XOR middle layer for C2 list, PE file as final payload. Cobalt Strike: Hex-encoded loader, XOR-encrypted beacon config, AES-encrypted C2 traffic. PowerShell downloaders: Base64 command line flag, URL-encoded download URL inside, Base64-encoded payload from server. Defense strategy: Use auto-detect to identify outer layer, Chain deobfuscation for each layer, Document the full chain for IOC extraction, Check for patterns (same XOR key across samples). This tool makes chaining easy with the Chain button - each successful decode becomes input for next layer.