DER Text Editor (der2ascii / ascii2der)

Why edit DER as text

DER is compact and exact, which makes it miserable to edit. Every element starts with a tag and a length, and the length of every enclosing element depends on it: change one byte of a name inside a certificate and four or five length fields above it have to change too. Hex editors leave that bookkeeping to you, and ASN.1 compilers refuse to produce anything the schema does not allow — precisely what you need when you are building a test vector, reproducing a parser bug, or checking how a library reacts to an INTEGER with a redundant leading zero.

DER ASCII, a format created by Google for BoringSSL's test suite (google/der-ascii), solves this. Each element is written as a tag followed by its content in braces, one per line, and lengths are computed when the text is compiled back:

SEQUENCE {
  OBJECT_IDENTIFIER { 1.2.840.10045.2.1 }
  OBJECT_IDENTIFIER { 1.2.840.10045.3.1.7 }
}

This editor is a faithful TypeScript port of the two upstream commands — der2ascii (bytes to text) and ascii2der (text to bytes) — so it runs entirely in the page, with output byte-for-byte identical to the Go tools on our test corpus of real certificates, CRLs, OCSP messages and RFC 4134 CMS samples.

From bytes to text

Paste a PEM block, base64, base64url or hex, or drop a binary file onto the page; files are read with the browser's File API and never uploaded. When the input holds several PEM blocks, each is converted, with its label as a # comment above it.

The converter reads full BER, not only DER, and it is deliberately lossless: elements it can describe are written by name (SEQUENCE, INTEGER { 65537 }, UTF8String { "…" }, object identifiers with their dotted value and a comment naming them), and anything it cannot describe — a non-minimal length, an indefinite length, bytes after the end of the structure, a string that is not valid in its type — is written in a form that reproduces the exact bytes: indefinite, long-form:2, a hex literal in backticks. The editor proves this on every conversion by compiling the text straight back and comparing it with the input; the result is reported as "lossless".

From text to bytes

The text area is yours. As you type, the text is compiled and the bytes shown as hex, base64 and PEM, with a download of the binary .der file. The syntax in brief:

• universal tags by name (SEQUENCE, SET, BIT_STRING, GeneralizedTime…), context and application tags in brackets ([0], [APPLICATION 3 PRIMITIVE]);
• integers and object identifiers as numbers, any bytes as hex in backticks, strings in quotes (UTF-8; u"…" and U"…" for UTF-16 and UTF-32), bit strings as b followed by bits in backticks;
• indefinite, long-form:N and adjust-length:N to write lengths DER would never produce;
• comments from # to the end of the line.

A syntax error is reported with its line and column. When the text compiles, the bytes are checked against the strict DER rules of ITU-T X.690 §10 (definite, minimal lengths; no trailing data) — a warning, not an error, because building malformed encodings on purpose is one of the main reasons to use this tool. The editor also recognises what the bytes are and suggests the matching PEM label: CERTIFICATE for an X.509 certificate (RFC 5280), CERTIFICATE REQUEST for PKCS #10 (RFC 2986), X509 CRL, PUBLIC KEY and so on, following RFC 7468.

What people use it for

• Test vectors. Take a valid certificate, change one field — a negative serial number, a critical unknown extension, a UTCTime without seconds — and see whether your parser rejects it.
• Understanding a structure. The text form, with OID names as comments, is often the fastest way to read a CMS message or an OCSP response line by line; for clicking through it with highlighted bytes, the ASN.1 explorer shows the same data as a tree.
• Fixing encodings. Re-wrap a BER file from a Windows or Java tool as clean DER, or extract one element and compile it on its own.

What runs where

Both conversions, the round-trip check, the DER check and the label suggestion run in your browser. The page makes no request with your data. Share links carry the input — or the edited text — in the URL fragment, which browsers never send to a server; text that compiles to a private key, a PKCS #12 file or an encrypted key is refused, as are pasted private keys in any encoding. The port's licence (Apache-2.0) and the list of changes made to the upstream code are kept next to the tool's source.