In short
A digital signature is a value you attach to a file to prove two things: that it really came from you, and that not a single byte has changed since you signed it. You create it by hashing the file and encrypting that hash with your private key; anyone can check it with your matching public key. On its own the signature only ties a file to a key, so a certificate from a trusted certificate authority is what connects that key to a verified identity — a person, a company, or a server. It's the same primitive behind HTTPS, signed software, signed PDFs, and secure email.
You rely on digital signatures dozens of times a day without seeing one. They're the reason your browser trusts a bank's website, the reason Windows lets an installer run without a scary warning, and the reason a signed contract holds up as evidence that nobody edited it after the fact. The idea underneath all of that is surprisingly small: prove authorship and detect tampering, using nothing but a pair of keys and a hash. Understand that one mechanism and a lot of security tooling stops looking like magic.
What is a digital signature?
A digital signature is a short cryptographic value, computed from a file and a private key, that proves who signed the file and confirms it hasn't been altered. Only the holder of the private key could have produced it, and anyone can verify it with the matching public key. It replaces the two jobs a handwritten signature was always meant to do — showing intent and making tampering obvious — with math that actually delivers on the second.
The word "signature" is a little misleading. Nothing about it looks like a name, and it isn't a picture of anything. It's a number, usually a few hundred bytes, that is mathematically bound to the exact contents of the thing you signed. Sign a one-line email and a 400-page PDF with the same key and you get two completely different signatures, because each is derived from that specific document. Change one comma in the PDF after signing and the signature no longer checks out.
That property is what makes it useful. A digital signature is the working part of public key infrastructure: the operation that lets one party make a claim and any other party check it, without the two ever sharing a secret. Certificates, certificate authorities, and the whole chain of trust exist to answer one follow-up question a raw signature can't — whose key was that?
How a digital signature works
Signing happens in two steps. First the file is run through a hash function, which condenses any amount of data into a fixed-length digest — a fingerprint that changes completely if the input changes at all. Then that digest is encrypted with the signer's private key. The encrypted digest is the signature, and it travels alongside the file. Verifying reverses the process with the public key.
Hashing first is what makes signing practical. Public-key operations are slow and work on small inputs, so signing a multi-gigabyte file directly would be painful. The hash gives you a tiny, fixed-size stand-in for the whole file, and because the hash is collision-resistant, signing the digest is as good as signing every byte. This is also why a signature is tied to one exact file: two different files essentially never share a digest, so a signature made for one can't validate another.
Notice which key does what. The private key signs and never leaves the signer; the public key only verifies and can be handed to anyone. That's the reverse of encryption, where you encrypt with a public key and decrypt with a private one. If the relationship between the two halves is fuzzy, the walk-through in symmetric vs asymmetric encryption lays out why one key can undo what the other did.
Where the certificate fits in
A signature by itself proves that someone holding a particular private key signed a file. It doesn't say who that someone is. A certificate closes that gap: a certificate authority verifies your identity, then issues a signed certificate that binds your public key to your name. Now a verifier can trust not just the key, but the organization behind it.
This is the difference between a signature that's merely valid and one that's trusted. Anyone can generate a key pair in seconds and sign a file, and that signature will verify perfectly against their public key — it just proves nothing about their identity. When a browser, an operating system, or a PDF reader accepts a signature, it's really trusting the chain of certificate authorities that vouched for the key. The signature answers "was this tampered with?"; the certificate answers "and can I trust who made it?"
The certificate also carries the rules for how the key may be used and how long it stays valid. Those constraints are why the same underlying math produces distinct products — a certificate issued for signing code is marked and validated differently from one issued for signing email or for a web server, even though the signing operation is identical underneath.
Digital vs electronic signatures
These two terms get swapped around constantly, and the difference matters. An electronic signature is any electronic indication that you agreed to something: a typed name, a clicked "I accept," an image of your handwriting dropped into a document. A digital signature is a specific cryptographic method that can back an electronic signature with real tamper-evidence and identity. Every digital signature is electronic; most electronic signatures are not digital.
The practical consequence shows up when a document is challenged. A typed name proves very little on its own — there's no way to tell from the file whether a clause was edited after signing. A digital signature makes that question answerable: if anything changed, verification fails, and the certificate names who signed. That's why higher assurance levels under frameworks like the EU's eIDAS lean on digital signatures, a point the guide to document signing certificates unpacks in more legal detail.
What a signature actually guarantees
A verified digital signature gives you three assurances at once. Integrity means the file hasn't changed since it was signed. Authenticity means it came from the holder of the private key. Non-repudiation means that signer can't later deny having signed it, because no one else could have produced the signature. Together they turn a file into something you can act on without trusting the channel it arrived through.
That last one, non-repudiation, is what sets public-key signatures apart from simpler integrity checks. A plain checksum tells you a file wasn't corrupted, but anyone can recompute it, so it proves nothing about who made it. A shared-secret code can prove a message came from someone who knew the secret — yet both parties know it, so neither can prove the other sent a given message. A private key is held by exactly one party, which is why a signature made with it can be pinned to that party and no one else.
One honest caveat: these guarantees are only as strong as the secrecy of the private key. If the key is stolen, an attacker can sign as its owner, and the math will happily verify those signatures. Everything downstream of a signature — trust in a signed app, a signed contract, a server certificate — ultimately rests on that one secret staying secret, which is why signing keys increasingly live on hardware tokens rather than plain files.
Where you already use them
The same signing operation shows up under different names across the web. In HTTPS, a server signs part of the TLS handshake to prove it holds the private key for its certificate. In software distribution, a publisher signs an installer so the operating system will run it without alarm. In documents and email, a person or company signs a file so recipients can confirm it's genuine and untouched.
What changes between these cases isn't the cryptography — it's the certificate and the validation behind it. A code signing certificate is validated and marked for signing software; a document signing certificate is issued for PDFs and Office files; an S/MIME certificate is tied to an email address. All three produce the same kind of signature, but each certificate tells the verifier what the key is allowed to vouch for. That's why picking the right certificate type matters as much as the signing step itself.
The algorithms behind the signature
A digital signature combines two algorithms: a hash function to fingerprint the file and a public-key algorithm to sign that fingerprint. In practice the hash is almost always SHA-256 (or its larger siblings SHA-384 and SHA-512), and the signing algorithm is RSA, ECDSA, or the newer EdDSA. The pairing you see most on the web is SHA-256 with either an RSA-2048 or an ECDSA P-256 key.
The hash choice is not cosmetic. SHA-1, an older function, has been broken to the point where forged collisions are practical, so it's been pushed out of the trusted certificate ecosystem — the CA/Browser Forum Baseline Requirements permit only SHA-256 and stronger for publicly trusted certificates. If you inspect a modern certificate and see SHA-256 as the signature algorithm, that's why. A signature is only as trustworthy as the hash underneath it, because a hash collision would let two different files share one signature.
There's a longer-horizon change coming. RSA and ECDSA both rest on math that a sufficiently large quantum computer could unravel, which would expose private keys. No such machine exists today, but in 2024 NIST finalized two quantum-resistant signature standards — FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) — as the eventual replacements. The move will start with signatures that must stay trustworthy for decades, like firmware and root keys. Our overview of post-quantum cryptography covers what that transition looks like in practice.
The bottom line
A digital signature is a small piece of cryptography that proves a file came from you and hasn't been altered, and a certificate is what attaches your verified identity to the key that made it. It's one primitive doing quiet work behind HTTPS, signed software, signed documents, and secure email. When you need a signature others will trust, the certificate type is the decision that matters — My-SSL issues document signing, code signing, and S/MIME certificates for exactly these jobs, and the document signing guide walks through choosing one.