PEM to DER, and back again
The same bytes in two wrappings. PEM is Base64 with header lines for pasting into config files; DER is the raw binary. Converting between them changes nothing about what the object is.
The DER inside a PEM file is byte-for-byte the DER you get out. Nothing is re-encoded, no field is rewritten, and no format is converted into another — a PKCS#1 key does not become a PKCS#8 one by passing through here. If you need that, openssl is the tool.
Input
Output
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
What the label means, and why it matters
The words between the dashes are not decoration. CERTIFICATE, PUBLIC KEY, PRIVATE KEY, CERTIFICATE REQUEST — each says what structure the DER inside is meant to be, and tools use it to decide how to parse what follows.
A label that does not match the contents produces confusing failures: a PKCS#1 RSA key labelled PRIVATE KEY — which means PKCS#8 — will be read by the wrong parser and rejected as malformed. This page detects what the structure actually looks like and says so, rather than trusting the label you started with.
What is not converted here
Encrypted private keys. A PEM starting -----BEGIN ENCRYPTED PRIVATE KEY----- holds a password-protected structure. Re-wrapping it is possible and pointless; decrypting it needs the password and is not something to do in a web page.
One key format into another. PKCS#1 to PKCS#8, or SEC1 EC keys to PKCS#8, are genuine re-encodings that rewrite the structure. This tool refuses rather than attempting them, because a converter that quietly produces something subtly different is worse than one that says no.
Anything requiring the private key. Nothing here signs, decrypts or derives.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
Which is which
PEM is what you paste into a config file: Base64 wrapped at 64 characters between -----BEGIN X----- lines. It survives email, YAML and copy-paste, and it is what most software expects by default.
DER is the same data as raw binary. Smaller, unreadable in a text editor, and what Java keystores, Windows tools and some embedded systems want. A .der or .cer file is usually this; a .crt or .pem is usually PEM, though the extensions are not reliable.
The equivalent openssl commands
For a certificate: openssl x509 -in cert.pem -outform DER -out cert.der and openssl x509 -inform DER -in cert.der -out cert.pem.
For a public key: openssl pkey -pubin -in key.pem -outform DER -out key.der.
Those do slightly more than this page: they parse the structure and re-emit it, which normalises anything unusual. This page moves the bytes across unchanged, which is what you want when you need to be sure nothing was altered.
Related
The certificate inspector and key inspector read what you have; the encoding converter handles encodings generally.
Questions people actually ask
What is the difference between PEM and DER?
The wrapping only. DER is the raw binary encoding of the structure; PEM is that same binary, Base64-encoded, wrapped at 64 characters, between BEGIN and END lines. Converting between them changes nothing about what the object is or means.
Does this convert one key format into another?
No, and it refuses rather than attempting it. PKCS#1 to PKCS#8, or SEC1 EC keys to PKCS#8, are genuine re-encodings that rewrite the structure. A converter that quietly produces something subtly different is worse than one that says no — openssl is the right tool for those.
Why does it tell me what the structure looks like?
Because a mislabelled PEM is a real and confusing failure. A PKCS#1 RSA key labelled "PRIVATE KEY" — which means PKCS#8 — gets handed to the wrong parser and rejected as malformed, with nothing to indicate why. The page inspects the actual shape rather than trusting the label it arrived with.
Can it handle encrypted private keys?
It can re-wrap one, which achieves nothing. Decrypting it needs the password, and that is not something to do in a web page — use openssl on your own machine.
My .der file was rejected.
If it began with BEGIN it was actually PEM despite the extension, and the page reads it as such and says so. If it is genuinely binary and still fails, it is probably not a DER structure at all — the page walks it and reports what it found.
Is the file uploaded?
No. It is read into your browser's memory and converted there. Nothing is transmitted, including private keys, which you should nonetheless be cautious about pasting into any web page.