PowerShell Encoded Command Decoder
PowerShell's -EncodedCommand (-enc) is Base64 of the command's UTF-16LE (Unicode) bytes — not UTF-8, which is why naive Base64 decoders show garbled, space-separated text. Paste the encoded string below to decode it back to the original PowerShell, or encode a command into the -enc form. Everything runs locally; nothing is uploaded.
-enc is common in malware and red-team tooling as well as legitimate automation. This decoder runs 100% in your browser — safe for analyzing suspicious commands; nothing is sent anywhere. Decoding a command does not run it.
How to decode a PowerShell encoded command
When you see powershell -enc <long-base64>, that Base64 blob is the whole command in disguise. To read it, copy the value that follows -enc or -EncodedCommand, paste it into the box above, and keep the toggle on Decode. The tool Base64-decodes the string to raw bytes and interprets them as UTF-16LE — the encoding PowerShell actually uses — to recover the original command. It all happens locally, and decoding never executes the command. Click Copy to grab the result.
Why UTF-16LE, not UTF-8?
This is the number-one gotcha. PowerShell's -EncodedCommand does not Base64 the command text as UTF-8 — it Base64s the command's UTF-16LE (Unicode) bytes, where every ASCII character is followed by a 0x00 byte. If you paste the string into a generic Base64 decoder that assumes UTF-8, those null bytes render as spaces or invisible control characters, and you get output that looks like W r i t e - H o s t — spaced out and garbled. Decode the same bytes as UTF-16LE and it reads cleanly as Write-Host. The classic obfuscated invocation looks like this:
powershell.exe -nop -w hidden -enc <base64>
Here -nop skips the profile, -w hidden hides the window, and -enc hides the actual command inside Base64. Decoding the trailing blob as UTF-16LE is what turns it back into readable PowerShell.
Decoding for malware analysis and incident response
Attackers lean on -enc because a single Base64 argument dodges naive command-line filters and hides intent from a casual glance. As a defender you want to see exactly what a suspicious process was told to do — without running it. Decoding here is purely a read operation: the bytes are transformed into text in your browser and never executed, so it is safe to paste command lines pulled from EDR alerts, Sysmon event ID 1, or Windows 4688 process-creation logs.
Sometimes one decode is not enough. A common second layer wraps a gzip- or deflate-compressed script that the malware decompresses at runtime with a MemoryStream and GzipStream. When the UTF-16LE result looks binary rather than text, this tool automatically retries with gzip/deflate decompression and shows the inflated payload, noting decoded + decompressed (nested payload) in the status. Even then, you are only reading it — nothing runs.
How to create an encoded command
Switch the toggle to Encode and type a command to get its -enc form. The tool encodes your text as UTF-16LE bytes and Base64s the result — exactly what PowerShell expects — so you can run powershell -enc <output>. This is a legitimate, everyday technique: admins use -enc to pass a multi-line script through a single command-line argument without wrestling with nested quotes and escaping, for example inside a scheduled task, a Group Policy startup script, or a remote management call. Encoding does not add any security — anyone can decode it back, exactly as this page does.
Is this private?
Yes, and it matters here. Because people paste command lines from real, possibly hostile samples, everything runs entirely in your browser with JavaScript — the string is Base64-decoded and interpreted locally and nothing is uploaded to any server. You can confirm in DevTools → Network that decoding fires no request. Close the tab and the pasted data is gone. Decoding also never executes the command; it only reveals its text.
Frequently asked questions
How do I decode a PowerShell -enc / -EncodedCommand string?
Paste the Base64 value that follows -enc or -EncodedCommand into the decoder above and keep it in Decode mode. It Base64-decodes the string to bytes and interprets them as UTF-16LE (Unicode) — the encoding PowerShell actually uses — to recover the original command, locally. Decoding does not run the command.
Why does my decoded command look garbled or spaced out?
You almost certainly decoded it as UTF-8. -EncodedCommand is Base64 of the command's UTF-16LE bytes, where each ASCII character is followed by a 0x00 byte. A UTF-8 decoder renders those null bytes as spaces or control characters, so the text looks spaced-out. Decode as UTF-16LE — which this tool does — and it reads cleanly.
How do I encode a command for -EncodedCommand?
Switch to Encode mode and type your command. It encodes the text as UTF-16LE bytes and Base64s the result — the exact form PowerShell expects — so you can run powershell -enc <output>. Admins use this to pass a multi-line script through a single argument without quoting headaches.
Is it safe to decode a malicious PowerShell command here?
Yes. Decoding is 100% local — the string is decoded in your browser and nothing is sent anywhere. Decoding only reveals a command's text; it never executes it. That makes this safe for analyzing suspicious or malicious samples during incident response.
What if the decoded output is still gibberish?
The payload may be gzip/deflate-compressed or multi-layered — attackers often compress a script, Base64 it, and decompress it at runtime. This tool automatically attempts decompression when the UTF-16LE result looks binary. For deeper nesting, feed the inner Base64 into the Base64 Gzip decoder and repeat.
Need plain Base64 encode/decode?
The main base64.dev tool handles text, files, and URL-safe mode with auto-detect.
Open base64.dev →