How to decode Base64 to UTF-16
- Paste the Base64 into Input · Base64. Charset is preset to UTF-16LE.
- Read the text in Output · text. The Looks like field will usually say Binary, because the detector treats zero bytes as a sign of binary data; the text output is still correct.
- If the result is a row of CJK-looking characters, switch Charset to UTF-16BE.
- If the data starts with a byte order mark, Auto-detect picks the right byte order and drops the mark.
- Copy output copies the text; Download saves the raw bytes.
For the reverse direction, see UTF-16 to Base64.
Recognizing UTF-16 in Base64
UTF-16 Base64 has a visible rhythm. ASCII text in UTF-16 alternates letter bytes with zero bytes, and zero bits map to A in the Base64 alphabet, so A shows up every few characters:
| Base64 | Byte order | Decoded |
|---|---|---|
SABlAGwAbABvAA== | LE, no BOM | Hello |
AEgAZQBsAGwAbw== | BE, no BOM | Hello |
//5IAGkA | LE with BOM FF FE | Hi |
/v8ASABp | BE with BOM FE FF | Hi |
RwBlAHQALQBEAGEAdABlAA== | LE, no BOM | Get-Date |
Big-endian ASCII text always starts with A, because its first byte is zero. A string starting with //4 or /v8 begins with a byte order mark.
Byte order, BOM and Auto-detect
Read with the wrong byte order, every pair of bytes is swapped and English turns into CJK ideographs: AEgAZQBsAGwAbw== decoded as UTF-16LE gives 䠀攀氀氀漀. Nothing is lost; switching Charset fixes it.
Auto-detect handles UTF-16 reliably when the data starts with a BOM. Without a BOM, plain ASCII text in UTF-16 is also valid UTF-8 (zero bytes are legal there), so automatic detection can mistake it for UTF-8 with invisible characters. On this page, keep UTF-16LE or UTF-16BE selected by hand unless you see //4 or /v8 at the start.
An odd number of bytes means something is off. SABpAAA= holds 5 bytes; decoded as UTF-16LE it gives Hi and a trailing �. Either the value was cut, or it is not UTF-16 at all.
Where UTF-16 Base64 comes from
The most common source is PowerShell. Encoded commands like powershell -enc SQBFAFgA... appear in scheduled tasks, installer scripts and security logs, and the Base64 is always UTF-16LE. The PowerShell EncodedCommand decoder extracts the value from a full command line and looks for further Base64 inside the script.
Other sources are .NET programs that call Convert.ToBase64String(Encoding.Unicode.GetBytes(...)), Windows registry and event data, and SQL Server NVARCHAR values exported as binary.
Decoding UTF-16 Base64 in code
import base64
raw = base64.b64decode("SABlAGwAbABvAA==")
raw.decode("utf-16-le") # 'Hello'
base64.b64decode("/v8ASABp").decode("utf-16") # 'Hi', byte order taken from the BOM
Python raises UnicodeDecodeError: truncated data on an odd byte count.
// Node.js: little-endian only
Buffer.from("SABlAGwAbABvAA==", "base64").toString("utf16le"); // "Hello"
// Browsers and Node.js: either order
new TextDecoder("utf-16be").decode(Uint8Array.from(atob("AEgAZQBsAGwAbw=="), c => c.charCodeAt(0))); // "Hello"
In C#, Encoding.Unicode.GetString(Convert.FromBase64String(s)) reads UTF-16LE and Encoding.BigEndianUnicode reads big-endian. See also Python and Node.js.
FAQ
How do I know if Base64 contains UTF-16?
Look for many A characters in a regular pattern, as in SABlAGwAbABvAA==: each ASCII letter in UTF-16 sits next to a zero byte. A leading //4 or /v8 is a UTF-16 byte order mark.
Why do I see Chinese characters after decoding?
The byte order is reversed. Big-endian Hello read as little-endian becomes 䠀攀氀氀漀. Switch Charset between UTF-16LE and UTF-16BE.
Why is there a � at the end of the text?
UTF-16 needs an even number of bytes. An odd count means the Base64 was cut or is not UTF-16, and the leftover byte becomes the replacement character.
How do I decode a PowerShell -EncodedCommand?
The value after -EncodedCommand (or -enc) is UTF-16LE Base64, so this page decodes it. The PowerShell decoder also accepts the whole command line and finds nested payloads.