Encoding & Decoding
Encode and decode Base64 in real-time. Learn why attackers use Base64 to obfuscate malware payloads, PowerShell commands, and phishing data, and how to decode them for analysis.
Base64 is an encoding scheme that converts binary data into ASCII text using a 64-character alphabet (A-Z, a-z, 0-9, +, and /). Each Base64 character represents 6 bits, so three bytes of input become four characters of output. Base64 is not encryption: it provides no confidentiality and can be reversed by anyone, which is exactly why it appears so often in security work as a tool for transport and, unfortunately, for obfuscation.
Legitimate uses of Base64 include embedding binary data in text formats like JSON and XML, transmitting binary attachments in email (MIME), and encoding small images or fonts directly in CSS and HTML. Because it is reversible and adds about 33% size overhead, Base64 is a transport convenience rather than a security measure. Understanding this distinction is critical: a Base64 string is plaintext in disguise, not a secret.
This tool encodes and decodes entirely in your browser, so you can safely inspect suspicious strings, deobfuscate payloads, and analyze data without sending anything to a remote service.
Because Base64 looks like opaque gibberish to a human but is trivially reversible, attackers use it to hide payloads from cursory inspection. A common pattern on Windows is the PowerShell -EncodedCommand flag, which accepts a Base64-encoded command that executes without the plaintext appearing in the script. Decoding these strings is often the first step in understanding what a suspicious script or macro actually does.
Malware authors also Base64-encode payloads, configuration data, and stolen credentials to evade signature-based detection that scans for readable strings. Web shells, phishing kits, and malicious browser extensions frequently store their next-stage payload as a Base64 blob that is decoded at runtime. Decoding the blob reveals the real intent, whether that is a reverse shell, a credential stealer, or a command-and-control beacon.
Data exfiltration is another abuse: attackers sometimes Base64-encode stolen data to smuggle it past filters that block raw binary or to hide sensitive content in otherwise normal-looking HTTP requests. Recognizing a long, high-entropy Base64 string in an unexpected place is a useful detection heuristic for analysts reviewing logs and traffic.
Detection of Base64 abuse relies on recognizing the character set, the typical length and padding (= or ==), and unusually high entropy. Security tools and SIEM rules can flag long Base64 strings in places they should not appear, such as a User-Agent header, a cookie, or a query parameter. This tool helps you manually decode any such string to determine whether it is benign data or a hidden payload.
When analyzing a suspicious string, decode it and inspect the result. If the decoded output is itself Base64 or another encoding, attackers may be nesting encodings to add layers of obfuscation, a technique you can peel back iteratively. If the decoded output is executable code, a shell command, or a script, treat it as potentially malicious and analyze it in a safe environment.
Remember that legitimate applications also use Base64 extensively, so presence alone is not malicious. Context matters: Base64 in an image data URI is normal, while Base64 passed to a PowerShell execution command is suspicious and deserves investigation.