ASN.1 DER Parser

ASN.1 DER Encoding

ASN.1 (Abstract Syntax Notation One) is an ISO/IEC 8824 standard for data structure description. DER (Distinguished Encoding Rules) is a binary encoding for ASN.1, used in X.509 certificates, PKCS structures, and smart card personalization data. Each data object is encoded as Tag-Length-Value (TLV).

If you have ever opened a .pem or .crt file and wondered what the Base64 blob inside actually means, ASN.1 DER is the answer. Every certificate, CRL, CSR (Certificate Signing Request), and PKCS#12 key bundle is serialized using these rules. The tree view above lets you drill into that binary structure without writing a single line of code.

DER vs BER: Why DER Wins for Cryptography

BER (Basic Encoding Rules) and DER are both defined in ITU-T X.690. They share the same TLV concept but differ in one critical aspect: BER allows multiple valid encodings of the same data (e.g., a SET can be in any order, a length can use short or long form interchangeably), while DER mandates a single canonical form. This is essential for digital signatures — if two parties encode the same data differently, the signature would not verify. DER enforces shortest-form length encoding, canonical SET ordering (sorted by DER encoding of each element), and primitive encoding for string types. CER (Canonical Encoding Rules) is a third variant rarely seen outside of certain telecom protocols.

Common Tag Types

INTEGER (0x02) stores signed integers. BIT STRING (0x03) stores bit-aligned data, with the first byte indicating unused bits. OCTET STRING (0x04) stores raw bytes. NULL (0x05) is used as a placeholder. OBJECT IDENTIFIER (0x06) encodes dotted notation like 1.2.840.113549.1.1.1 (RSA encryption). SEQUENCE (0x30) groups multiple objects. SET (0x31) is similar but unordered. UTCTime (0x17) and GeneralizedTime (0x18) encode timestamps. Context-specific tags (0x80-0xBF) are used for implicitly tagged elements in certificates.

Anatomy of an X.509 Certificate

When you decode a certificate with this parser, the top-level structure is always SEQUENCE, containing two nested objects: a tbsCertificate SEQUENCE and a signatureAlgorithm SEQUENCE followed by a signatureValue BIT STRING. Inside tbsCertificate you will find the version (context tag [0]), serial number (INTEGER), signature algorithm (OID), issuer name (SEQUENCE of SET of AttributeTypeAndValue), validity (two UTCTime or GeneralizedTime entries), subject name, subject public key info (an algorithm OID plus a BIT STRING containing the actual key bytes), and optional extensions wrapped in context tag [3]. Understanding this hierarchy makes it possible to verify whether a certificate was tampered with, extract the public key for custom verification, or inspect the X.509 v3 extensions chain — Subject Key Identifier, Authority Key Identifier, Key Usage, Extended Key Usage, Certificate Policies, and CRL Distribution Points are all encoded as SEQUENCE of OID-tagged structures.

OID Registry: The Global Type System

Object Identifiers (OIDs) form a hierarchical, globally unique naming system managed by ISO and ITU-T. The root arcs are 0 (ITU-T), 1 (ISO), and 2 (joint-iso-itu-t). Common sub-arcs include 1.2.840 (RSA Security), 1.2.840.10045 (ANSI X9.62 ECC), 2.5.4 (X.520 attribute types like CN, O, OU), 2.16.840.1.101.3.4 (NIST hash algorithms including SHA-256/384/512), and 1.3.6.1.5.5.7 (IETF PKIX certificate extensions). When you see a new OID in the parser output, you can look it up in the IANA or OID repository to identify the algorithm, attribute, or extension it represents.

PKCS Structures You Will Encounter

Beyond X.509, several PKCS standards rely on ASN.1 DER. PKCS#7 (CMS, OID 1.2.840.113549.1.7.2) wraps signed data with certificates and CRLs for S/MIME email. PKCS#8 (OID 1.2.840.113549.1.8) describes private key information, often nested inside PKCS#12 (PFX) bundles that combine a key, its certificate, and a CA chain with password-based encryption. PKCS#10 certificate signing requests follow a similar pattern: SEQUENCE { certificationRequestInfo, signatureAlgorithm, signature }. Each of these can be pasted into this parser to inspect the nested TLV structure in seconds.

Smart Card Personalization Data

On the card side, ASN.1 appears in GlobalPlatform personalization scripts, EMV card risk management parameters (packed in BER-TLV format), and 3GPP USIM file structures (EF_DIR and EF_SPN). The line between BER and DER blurs on cards — some issuers use BER-style indefinite-length encoding (tag 0x30 followed by 0x80 for length, terminated by 00 00), which is technically non-compliant with DER. This parser handles both definite and indefinite-length constructed types gracefully.

Decoding Process

The parser reads each TLV triple: first the tag (1-2 bytes, multi-byte if low 5 bits are all 1s), then the length (short form if < 128, long form if first byte is 0x81-0x84 indicating how many subsequent bytes hold the length), then the value. Constructed types (bit 6 of tag set) have nested TLV structures in their value field. The parser recursively decodes these structures and displays them as a tree. Use with our X.509 Certificate Parser and BER-TLV Parser for related formats.

Frequently Asked Questions

What input formats are accepted? Hex strings (with or without spaces) and Base64 (with or without PEM headers). The parser auto-detects the format. If your input has -----BEGIN CERTIFICATE----- wrappers, strip them first — or just paste the Base64 body.

Does this work with indefinite-length encoding? Yes. Constructed types with length byte 0x80 are decoded recursively until the end-of-contents marker (00 00) is found.

Can I parse a full certificate chain? Yes. A PKCS#7 SignedData structure or a PKCS#12 PFX file containing multiple certificates will display every certificate as a separate SEQUENCE node in the tree.

Is my data sent to a server? No. All parsing runs entirely in your browser using JavaScript. No network requests are made with your DER data. This is safe for inspecting production certificates and private key material.