PEM File Documentation

Summary

A PEM (Privacy-Enhanced Mail) file is a plain-text container for cryptographic data, most often an X.509 TLS certificate, a public or private key, or a certificate chain. The data is Base64-encoded and wrapped between -----BEGIN ...----- and -----END ...----- lines, with a MIME type of application/x-pem-file. The name comes from a 1990s secure-email standard, but a modern .pem almost always holds certificates and keys, not email. You can read it in any text editor, but you use it with tools like OpenSSL or a web server.

Technical details

FeatureValue
Full namePEM — Privacy-Enhanced Mail (now a Base64 certificate/key container)
File extension.pem
MIME typeapplication/x-pem-file
Format typePlain-text: Base64-encoded DER wrapped in -----BEGIN/END----- lines
DeveloperIETF — origin in the Privacy-Enhanced Mail RFCs, encoding codified in RFC 7468
IntroducedPEM email RFCs 1421–1424 (1993); textual encoding standardised in RFC 7468 (2015)
Standard / specRFC 7468 (Textual Encodings of PKIX, PKCS and CMS Structures)
Open standardYes
Character encodingASCII / printable text (Base64 alphabet)
Underlying dataDER-encoded ASN.1 (X.509 certificate or PKCS key)
Base64 line length64 characters per line (RFC 7468), except the final line
Boundary delimiterExactly five hyphens each side: -----BEGIN CERTIFICATE-----
Common labelsCERTIFICATE, PRIVATE KEY, RSA PRIVATE KEY, EC PRIVATE KEY, PUBLIC KEY, CERTIFICATE REQUEST
Multiple blocksYes — a chain (server cert + intermediates) and/or a key can share one file
Magic numberNone (text) — starts with the ASCII line -----BEGIN
Binary equivalentDER (.der, .cer); bundled form is PKCS#12 (.p12, .pfx)
Related extensions.crt, .cer, .key, .der, .p12, .pfx, .csr, .asc
Primary toolOpenSSL (inspect and convert)
Specification URLrfc-editor.org/rfc/rfc7468
Structure at a glance

A PEM file is plain text with no binary signature. Each block opens with a pre-encapsulation boundary of the form -----BEGIN <label>-----, contains Base64-encoded DER data wrapped at 64 characters per line, and closes with a matching post-encapsulation boundary -----END <label>-----. The delimiter is exactly five hyphens on each side (RFC 7468). The <label> tells you what the block holds: CERTIFICATE (an X.509 public cert), PRIVATE KEY / RSA PRIVATE KEY / EC PRIVATE KEY (a secret key), PUBLIC KEY, or CERTIFICATE REQUEST (a CSR). A single .pem may concatenate several blocks, such as a server certificate, its intermediate chain, and a private key.

What is a PEM file?

PEM stands for Privacy-Enhanced Mail, a set of IETF standards published in 1993 as RFCs 1421 through 1424 for encrypting and signing email. That email system never saw wide adoption, but one part of it survived and outgrew its origin: the text encoding it used to wrap binary cryptographic data in printable characters. Today a .pem file almost never has anything to do with email. It is a container for an X.509 certificate, a public or private key, or a certificate chain, and its encoding is now standardised on its own by RFC 7468 (2015). So the historical name is genuine, but the modern meaning is "the text form of a certificate or key".

The reason the encoding stuck is practical. Certificates and keys are natively binary (DER, described below), and binary does not survive being pasted into a config file, copied through a terminal, or included in an email or a web form. PEM wraps that binary in Base64 and adds human-readable delimiter lines, producing something you can safely move as text. When you install a TLS certificate on a web server, connect to a cloud server over SSH with a .pem key, or import a CA certificate to trust an internal service, you are handling PEM.

The encapsulation boundaries: BEGIN and END lines

A PEM file is one or more blocks. Each block has three parts: an opening line, a Base64 body, and a closing line. RFC 7468 calls the opening line the pre-encapsulation boundary and the closing line the post-encapsulation boundary, and it is strict about their exact form.

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ
RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSAwHgYD
... (Base64, wrapped at 64 characters per line) ...
Ax9RfEjT8/9235135xzHZL5DzhP+m8yGfDrbAdv3wNiw==
-----END CERTIFICATE-----

The boundary must have exactly five hyphen-minus characters on each side, no more and no fewer, then the keyword BEGIN or END, a space, and a label. The label on the END line must match the one on the BEGIN line. The Base64 body between them is wrapped so that every line is exactly 64 characters except the last. Unlike the legacy 1993 PEM, RFC 7468 does not allow header fields (such as encryption hints) between the boundaries; the body is pure Base64 and nothing else. That strictness is what lets a parser reliably find and decode a block no matter what surrounds it in the file.

The label: what the block actually holds

The label in the boundary line is the single most useful thing in a PEM file, because it tells you what kind of object the block is without decoding anything. The distinction between a certificate and a private key, in particular, is the difference between a file you can publish and a file you must guard.

LabelContents
CERTIFICATEAn X.509 public certificate (for example a website's TLS cert). Safe to share.
CERTIFICATE REQUESTA PKCS#10 certificate signing request (CSR) sent to a CA.
PRIVATE KEYA PKCS#8 private key. Secret — never share.
RSA PRIVATE KEY / EC PRIVATE KEYOlder PKCS#1 / SEC1 private key forms. Secret.
ENCRYPTED PRIVATE KEYA password-protected private key.
PUBLIC KEYA SubjectPublicKeyInfo public key. Shareable.
X509 CRLA certificate revocation list.

Reading the first line of a .pem in a text editor answers the question people most often have: is this a certificate (public) or a key (secret)? If it says PRIVATE KEY in any form, treat the file like a password.

Base64 over DER: what the body decodes to

Strip the boundary lines and un-wrap the Base64 body and you get DER: the Distinguished Encoding Rules, a canonical binary serialisation of an ASN.1 data structure. ASN.1 is the schema language that defines what an X.509 certificate or a PKCS key looks like (its fields, types and order), and DER is one exact byte-for-byte way to write that structure down. PEM is therefore a thin two-step transform on top of DER: take the DER bytes, Base64-encode them, and add labelled delimiter lines. Nothing about the certificate's actual content changes; only its outer wrapping does.

This is why the same certificate can appear as either a .pem or a .der/.cer file: the PEM is the text form, the DER is the raw binary form, and converting between them is pure re-encoding with no loss. It also explains why "PEM" and "CRT" overlap so heavily. A .crt or .cer file usually just holds a certificate that is itself PEM- or DER-encoded, so a PEM certificate often already is a valid .crt. The extension is a convention about intended use, not a different format.

How PEM relates to CRT, CER, KEY, DER and PFX

Several certificate extensions describe the same small set of objects in different packaging, and the naming causes constant confusion. .crt and .cer normally hold a single certificate, in either PEM text or DER binary. .key holds a private key, usually PEM-encoded. .der is the raw binary form of any of these. A .p12 or .pfx is different in kind: it is a PKCS#12 archive that bundles a certificate, its chain, and the matching private key together in one password-protected binary file, which is what Windows and Java tools often expect.

Because these are all views of the same DER structures, converting among them is routine with OpenSSL, and it is mechanical rather than lossy. To bundle a PEM certificate and its key into a PKCS#12 archive:

openssl pkcs12 -export -in cert.pem -inkey key.pem -out bundle.pfx
openssl x509  -in cert.pem -outform der -out cert.der   # PEM cert to binary DER
openssl x509  -in cert.pem -text -noout                 # human-readable dump

The -text -noout form is how you actually "read" a certificate: it decodes the DER and prints the subject, issuer, validity dates, serial number and public-key details in plain text. There is also a common SSH case: a cloud provider (notably AWS EC2) hands you a private key as a .pem, and on Linux or macOS you connect with chmod 600 key.pem then ssh -i key.pem user@host. On Windows you either use OpenSSH the same way or convert the key to PuTTY's .ppk format with PuTTYgen.

Handling private keys safely

The security of PEM turns entirely on one distinction, so it is worth stating plainly. A block labelled CERTIFICATE or PUBLIC KEY is public by design: it is meant to be handed out, and sharing it exposes nothing. A block labelled PRIVATE KEY, RSA PRIVATE KEY or EC PRIVATE KEY is the secret half of the pair. Anyone who obtains it can impersonate your server, decrypt traffic that was encrypted to you, or log into the cloud instance the key unlocks.

The concrete mistake to avoid is pasting a private-key .pem into an online "PEM viewer" or "certificate converter". Those sites receive your key verbatim, and once a private key has touched a third party it must be considered compromised and reissued. Do every inspection and conversion locally with OpenSSL, which needs no network. Two operational habits matter as well: SSH refuses to use a key file that is readable by other users, which is why chmod 600 key.pem is required before ssh -i will accept it; and an ENCRYPTED PRIVATE KEY block is protected by a passphrase, so keeping keys encrypted at rest limits the damage if a file leaks. The PEM file itself is inert text and cannot execute; the risk is entirely about who can read the secret it contains, not about opening the file.

Frequently asked questions

How can I tell if a .pem is a certificate or a private key?

Open it in any text editor and read the first line. -----BEGIN CERTIFICATE----- means it is a public certificate, safe to share. -----BEGIN PRIVATE KEY----- (or RSA PRIVATE KEY / EC PRIVATE KEY) means it is a secret key you must protect. A single file can contain both, as separate blocks.

Why do PEM and CRT look identical?

Because a .crt file usually contains exactly the same thing: a certificate encoded as Base64 over DER between BEGIN/END lines. PEM names the text encoding; CRT names the intended use (a certificate). A PEM certificate is often already a valid .crt, and you can rename or split it as tools require.

Is it safe to upload my .pem to an online converter?

Only if it is a certificate. If the file contains a private key, never upload or email it: the operator of the site then has your secret and could impersonate you, and the key should be treated as compromised. Convert locally with OpenSSL instead, which does everything offline.

References