Why generic Base64 decoders produce garbage here

Base64 is just an encoding for arbitrary bytes — it says nothing about what those bytes mean once decoded. Most Base64 you encounter on the web wraps UTF-8 text, one byte per ASCII character, which is why a generic decoder usually "just works." PowerShell's -EncodedCommand is the exception: internally, .NET strings are UTF-16, so when PowerShell Base64-encodes a command for that flag, it encodes the UTF-16LE bytes — two bytes per character, most of them ASCII characters followed by a null byte. Feed that into a decoder expecting UTF-8 and every other byte is a stray null, producing the classic "letters separated by garbage" output. This tool decodes as UTF-16LE specifically because that's what PowerShell itself actually produces.

Why this shows up in incident response specifically

Encoded commands are a common way both legitimate automation and malicious payloads pass a script to `powershell.exe` while avoiding shell quoting/escaping issues — the entire command becomes one opaque Base64 blob on the command line. That opacity is exactly why it's worth decoding during investigation: a process command line, an EDR alert, or Windows Event ID 4104 (PowerShell script block logging) will often show only the encoded form, and reading the actual command it represents is the difference between "some PowerShell ran" and knowing precisely what it did.