Please Note: Encryption Consulting LLC does not possess, store, or retain any data entered into this decoder. All inputs, including PEM certificates, Base64-encoded DER, or hex strings, are used solely for decoding purposes and are not saved.
Frequently Asked Questions
Everything you need to know about decoding your CSR files. Can't find the answer you're looking for? Send us an email and we'll get back to you as soon as possible!
How to decode a CSR file using EC's ASN.1 Decoder tool?
Decoding ASN.1 data has never been easier. Open the ASN.1 Decoder tool and follow three straightforward steps.
Paste, upload, or drag and drop the CSR file into our tool. You can provide a PEM certificate, Base64-encoded DER, or a hex string, or upload .cer, .crt, .pem, or .der files.
Refine the output by trimming long hex values for better readability, enabling the hex dump view to inspect raw bytes, and aligning the decoded structure with RFC-defined formats to better understand each field.
Once processed, the tool displays a complete, hierarchical ASN.1 tree. You can explore all elements, including subject details, public key information, and other embedded components in a clear, structured format.
To generate a CSR, you can use our CSR Generator Tool. This utility simplifies the entire process of creating a CSR while ensuring compliance.
What do Offset, Length, and Value mean in the decoded tree?
Every field in the decoded tree shows three key properties when we hover over the field:
Offset is the byte position where that field starts in the binary data. For example, Offset: 772 means the field begins at byte 772 from the start of the file.
Length is displayed in the format 4 + 751 (constructed), where the first number is the size of the length and tag encoded, the second is the content size, and constructed means the field is a container holding nested fields inside it rather than a raw value.
Value is the decoded content of that field, such as an OID like sha256WithRSAEncryption, a text string like CN=example.com, or a raw hex sequence.
What is RFC/Structure Match, and why does the decoded content change when it is switched?
RFC/Structure Match is a schema or blueprint that tells the decoder how to label the raw binary fields in your file. The actual bytes never change; only the interpretation does.
When RFC/Structure Match is enabled, the decoder enforces the exact field names, nesting order, and hierarchy defined in the RFC. For instance, under RFC 5280, the validity block must contain exactly notBefore and notAfter in that order, and the subject must be a SEQUENCE OF RDNs (Relative Distinguished Name). This makes the decoded tree precisely match the official specification, which is useful for debugging malformed certificates or validating strict compliance.
What does the match percentage mean, and how is it calculated?
The percentage shows how well your data matches a known schema. The decoder runs your binary data against all known ASN.1 schemas and scores based on the fields present. The percentage is calculated as:
(successfully matched fields / total expected fields in schema) × 100
For instance, an X.509 Certificate schema expects fields like tbsCertificate, serialNumber, issuer, validity, subject, subjectPublicKeyInfo, and signatureAlgorithm. If your DER-encoded input matches 18 out of 23 expected fields, the score is ~78% X.509 Certificate. Required fields that are missing penalize the score more than optional ones.