Convert certificates and keys between PEM (Base64 text) and DER (binary) encoding formats.
PEM and DER are two containers for the same certificate or key data. PEM is the readable form: base64 text wrapped in lines like -----BEGIN CERTIFICATE-----. DER is the raw binary inside that wrapping. This tool converts either direction by adding or removing the armor lines and base64-encoding or decoding, so the underlying bytes never change. Everything runs in the browser; nothing is uploaded. The surprise for most users: conversion does nothing beyond re-wrapping. It does not encrypt, decrypt, sign, or validate. A PEM file is not an encrypted 'safe text' version of DER; it is the identical data presented differently, and converting cannot fix a broken certificate.
A concrete input and expected output from the current implementation.
Input
-----BEGIN CERTIFICATE----- MAMCAQE= -----END CERTIFICATE-----
Expected output
30 03 02 01 01 (the five DER bytes, shown as hexadecimal)
Removing the two armor lines leaves MAMCAQE=, which base64-decodes to five bytes: 30 03 02 01 01. That is a DER SEQUENCE (0x30) three bytes long (0x03) wrapping an INTEGER (0x02) of length 1 (0x01) with value 1 (0x01). A real certificate is the same encoding with dozens of fields; this tiny block only illustrates the transformation.
To convert PEM to DER, drop the -----BEGIN ...----- and -----END ...----- lines and any trailing whitespace, then base64-decode the remaining text into bytes. What is left is the DER encoding itself: a length-prefixed ASN.1 structure, in practice a SEQUENCE holding certificate fields or key integers such as modulus and exponent. No other transformation applies, so the certificate's binary form emerges byte for byte.
Converting DER to PEM runs the process backward: base64-encode the binary, break the text into 64-character lines, and surround it with a BEGIN/END pair whose label (CERTIFICATE, PRIVATE KEY, and so on) announces the payload type. The label is a hint for whatever program reads the file, so matching it to the content matters more than the encoding mechanics, which are a plain round trip.
Essentially yes. Both hold the same DER bytes; the PEM version is larger because base64 text expands the data by about a third and the armor lines add overhead. Nothing is encrypted or compressed in either direction, so converting never changes the certificate's meaning, only how it is presented to other software.
No. PEM and DER hold identical bytes, so a certificate that fails validation in one form fails the same way in the other. If a system rejects your file, check the armor label and inner format (PKCS#1 versus PKCS#8), whether the private key matches the certificate, and the trust chain. Re-encoding repairs none of those.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.