Contact

Tools  /  Security  /  PEM Decoder

SECURITY

PEM Decoder

A classic hexdump-style byte viewer for any PEM/base64/hex block, with hex/decimal/octal/C-array/binary exports and Shannon entropy.

More Security tools

SHA File Checker HTTP Security Header Reference Password Entropy Calculator Hash Generator Password Generator JWT Decoder & Generator

What this tool does

Decodes a PEM block (or raw base64/hex, or an uploaded binary file) down to its actual bytes and shows them as a classic offset / hex / ASCII hexdump — the same three-column layout tools like hexdump -C or xxd produce — plus the same bytes re-exported in six other common formats. This is a lower-level, byte-focused companion to this site's PEM Formatter (which builds/strips PEM text) and Certificate / DER Structure Viewer (which decodes the actual X.509 fields) — this one is for looking directly at the raw bytes themselves.

Reading a hexdump

Each row shows a byte offset (in hex, from the start of the data), up to 16 hex byte values split into two groups of 8, and the same 16 bytes rendered as ASCII on the right (a printable character where one exists, a . where it doesn't). Key and certificate bytes are mostly non-printable binary data, so the ASCII column will mostly show dots — that's expected, not a sign anything is wrong.

Export formats

Beyond the hexdump view: continuous hex (no spaces, good for pasting into code), colon-separated hex (the format openssl prints fingerprints and serial numbers in), decimal CSV, octal escapes (\NNN per byte, useful for shell strings), a ready-to-compile C byte array declaration, and a raw binary (0s and 1s) view.

Shannon entropy

A live Shannon entropy figure (0–8 bits per byte) measures how evenly the byte values are distributed. Real key and certificate material — DER-encoded, effectively compressed — typically sits close to 7.5–8 bits/byte. A much lower figure on something that's supposed to be key material is worth a second look; it can indicate accidental double-encoding, truncation, or that the input wasn't actually binary key data at all.

Printable-byte ratio

The percentage of bytes that fall in the printable ASCII range (0x20–0x7E). Genuine DER bytes are mostly non-printable, so this ratio is normally low (often under 20%) — a surprisingly high ratio usually means the "bytes" are actually still base64 or PEM text that didn't get decoded, rather than real binary.

Flexible input

Paste a full PEM block (headers are stripped automatically), raw base64, or raw hex — the format is auto-detected — or drag-and-drop / upload a binary file directly, read byte-for-byte via FileReader rather than as text.

Large inputs

Hexdump and binary views are capped at the first 64 KB to keep the page responsive on an unusually large file; every export format states clearly when it's showing a truncated view.

Privacy

Everything — decoding, hex dumping, entropy calculation — happens entirely in your browser. Nothing is uploaded; there is no server component to this tool.

FAQ

Frequently asked questions

How is this different from PEM Formatter or the Certificate Viewer?
PEM Formatter builds and strips PEM text (base64 to/from PEM headers and wrapping). The Certificate Viewer decodes a certificate's actual X.509 fields (Subject, Issuer, extensions). This tool is for looking at the raw bytes themselves -- a hexdump and several byte-export formats -- which neither of those is built to show.
Why does the ASCII column mostly show dots?
Key and certificate bytes are DER-encoded binary data, not text -- most byte values fall outside the printable ASCII range, so a dot is the correct, expected result for almost every byte. A few readable characters (like a few letters from an OID or a short string) scattered in is completely normal.
What does the Shannon entropy figure tell me?
It measures how evenly distributed the byte values are, from 0 (highly repetitive) to 8 (maximally even) bits per byte. Real DER-encoded key/certificate bytes usually sit around 7.5-8 -- a much lower number on something that's supposed to be key material can be a sign of double-encoding, truncation, or that it isn't actually binary data.
Why is the printable-byte ratio usually so low?
Because genuine binary key/certificate bytes rarely fall in the printable ASCII range by chance -- a low ratio (often under 20%) is the expected, healthy result. A surprisingly high ratio usually means what was pasted is still base64/PEM text rather than actually-decoded bytes.
Can I decode a raw binary file, not just pasted text?
Yes -- drag it onto the input box or use the upload button. It is read as actual bytes via FileReader, not as text, so it decodes correctly regardless of what it contains.
What happens with a very large file?
The hexdump and binary views cap at the first 64 KB to keep the page responsive, and clearly say so when a view is truncated. The other export formats behave the same way.
Can I export the bytes for use in code?
Yes -- the C byte array format gives a ready-to-compile unsigned char array declaration, and continuous/colon-separated hex and decimal CSV cover most other languages' literal syntax directly or with minimal editing.
Is anything I paste or upload sent anywhere?
No. Decoding, hex dumping and every export format are computed entirely in your browser -- this tool has no server component at all.
Theme Accent