ASN.1 Viewer

Decode any ASN.1 DER structure into a readable tag / length / value tree. Paste base64, a hex string, or a full PEM block, or load a file, and the viewer walks the binary byte by byte, showing each element's type, length and byte offset, decoding integers, strings, object identifiers, times and more, and resolving common OIDs to names like commonName, rsaEncryption and prime256v1. Pick the input format or let it auto-detect. Everything runs in your browser, so certificates, keys and signatures stay on your machine.

How to use the ASN.1 Viewer

Paste whatever encoding you have and leave Input on auto-detect, or force a specific format if the guess is wrong. The viewer strips a PEM wrapper if present, decodes base64 or hex to raw bytes, and walks the DER as a tree. Each node shows its ASN.1 type, its length in bytes, its byte offset into the data, and — for primitive values — the decoded content. Constructed types such as SEQUENCE and SET nest their children beneath them, so the indentation mirrors the structure precisely. You can also load a .der, .cer or .crt file directly; binary files are read as raw bytes and text files are decoded as PEM, base64 or hex.

Object identifiers are resolved to readable names where known, integers are shown in decimal when small and hex when large, the various string types are decoded by their tag, and UTCTime and GeneralizedTime values are shown as written. Context-specific tagged elements appear as [0], [1] and so on. The decoder also looks inside BIT STRING and OCTET STRING wrappers when their contents are themselves valid DER, which is how nested structures like a key inside a SubjectPublicKeyInfo become visible. The byte offset on every node makes it easy to cross-reference a hex dump or pinpoint exactly where a malformed structure goes wrong. Nothing you paste is transmitted; the entire parse runs locally.

ASN.1, BER, DER and the TLV model

ASN.1 — Abstract Syntax Notation One — is a standard, language-neutral way to describe the structure of data: what fields exist, what types they have, which are optional, how they nest. Crucially, ASN.1 separates the abstract description from how the data is actually written down. The same ASN.1 schema can be serialised by several different encoding rules. BER (Basic Encoding Rules) is the flexible original, allowing more than one valid byte representation of the same value. DER (Distinguished Encoding Rules) is a strict subset of BER that permits exactly one canonical encoding, which is why anything that gets signed — certificates, CSRs, signatures — uses DER: two parties must agree on the exact bytes. CER (Canonical Encoding Rules) is a third variant for streaming large values. This viewer reads DER, and most well-formed BER too.

Every encoding is built on one recursive idea: tag, length, value, usually abbreviated TLV. A tag byte says what the element is — its class (universal, application, context-specific or private), whether it is primitive or constructed, and its number, which for universal types names the kind: 02 INTEGER, 06 OBJECT IDENTIFIER, 30 SEQUENCE, 31 SET, and so on. The length says how many bytes the value occupies, using a short form for lengths up to 127 and a long form for larger ones. The value is those bytes — and for constructed types the value is itself a sequence of TLV elements, which is exactly how arbitrarily nested structures are formed. Reading ASN.1 is just walking that tree, and because the tags announce each type, the data is fully self-describing.

ASN.1 is one of those technologies that is everywhere yet almost invisible. It is the encoding beneath X.509 certificates and the entire TLS/PKI ecosystem, beneath the PKCS family of standards (PKCS#1 RSA keys, PKCS#7/CMS messages, PKCS#8 private keys, PKCS#10 CSRs, PKCS#12 bundles), beneath LDAP directory protocol messages, beneath SNMP network management, and beneath the signalling protocols of telecom and 5G networks. The object identifier — a globally registered dotted-number path like 1.2.840.113549.1.1.11 — is the glue that names algorithms, attributes and extensions across all of them, and turning those numbers back into names is most of what makes a decoded structure legible. Because the binary is opaque and library error messages are notoriously terse, seeing the actual TLV tree, with offsets and resolved OIDs, is usually the fastest way to understand what a cryptographic or protocol blob really contains.

Common use cases

  • Decoding any DER blob. Inspect base64 or hex pulled from a log, a packet capture or an API without knowing in advance what it is.
  • Reading certificates and keys. Walk the structure of an X.509 cert, a public or private key, or a signature.
  • Debugging protocols. Examine ASN.1 messages from LDAP, SNMP, CMS or telecom stacks down to the byte.
  • Cross-referencing a hex dump. Use the per-node byte offset to line the tree up with raw bytes when chasing a malformed encoding.
  • Private debugging. Inspect internal cryptographic material locally without uploading it anywhere.

Frequently asked questions

What input formats does it accept?
Base64, hex (with or without spaces or 0x prefixes), and full PEM blocks. Leave the Input selector on auto-detect to have it choose, or set it explicitly. You can also load a file: binary .der or .cer files are read as raw bytes, and text files are decoded as PEM, base64 or hex.

What is the difference between BER and DER?
BER (Basic Encoding Rules) is flexible and allows several valid byte representations of the same value. DER (Distinguished Encoding Rules) is a strict subset that allows exactly one canonical encoding, which is required for anything signed, like certificates and CSRs. This viewer targets DER and reads most well-formed BER as well.

What does the TLV tree show?
Each node is one ASN.1 element: its tag (the type, such as SEQUENCE, INTEGER or OBJECT IDENTIFIER), its length in bytes, its byte offset into the data, and its decoded value for primitives. Constructed types show their children indented beneath them, so the indentation mirrors the nesting exactly.

Why are some elements shown as [0], [1] and so on?
Those are context-specific tagged elements, the optional or positional fields ASN.1 uses heavily, for example in certificates. The number is the tag. Their meaning depends on the surrounding schema rather than a universal type, so the viewer shows the tag number rather than guessing a name.

Is my data sent anywhere?
No. The decode runs entirely in your browser with no network calls, so certificates, keys, signatures and protocol messages you paste never leave your device. That makes it safe for internal or private data.