If you run a website, you’ve already met encryption even if you’ve never used the word. It’s the 🔒 padlock in the browser bar, the reason your host told you to stop using plain FTP, and the checkbox on your backup settings that says “encrypt archive.”

Encryption is one of the few security controls that works quietly and almost never needs your attention, which is exactly why it’s easy to misunderstand. Plenty of site owners install an SSL certificate, see the padlock appear, and assume the site is now “secure.” That’s the gap we want to close here.

In this guide we’ll define encryption in plain language, walk through how it actually works, cover the main types you’ll run into, map each one to a specific place on your website, and, just as important, be clear about the attacks encryption does nothing to stop.

Contents:

• What is encryption?
• How does encryption work?
• What happens to your data when it’s encrypted?
• Types of encryption: symmetric vs asymmetric
• Encryption in transit, at rest, and end-to-end
• Where encryption shows up on your website
• What encryption does not do
• Is encryption good or bad?
• Where to start if you’re reviewing your own site
• Frequently asked questions

What is encryption?

Encryption is the process of taking readable data and transforming it, using a mathematical algorithm and a secret value called a key, into output that can’t be read without that key. The readable version is called plaintext. The scrambled version is called ciphertext. Reversing the process is decryption.

The important part isn’t the algorithm; it’s the key. Modern encryption algorithms are public and published; anyone can read exactly how they work. Security comes from the fact that you hold the key and an attacker doesn’t. That’s a deliberate design choice, because an algorithm that’s been reviewed by thousands of cryptographers for years is far more trustworthy than one kept secret.

So when someone says data is “encrypted,” the useful follow-up question is always: encrypted with what key, and who else can get to it?

How does encryption work?

Start with a toy example. Take the word LOGIN and shift every letter forward by three places in the alphabet: you get ORJLQ. The algorithm is “shift each letter,” the key is “three,” and the ciphertext is ORJLQ. Anyone who knows both the algorithm and the key can shift back and recover the original.

That example is trivially breakable because there are only 25 possible keys, and you could try them all by hand. Real encryption keeps the same shape but changes the scale. Instead of shifting letters, algorithms like AES operate on blocks of raw bytes, mixing and substituting them through many rounds. Instead of 25 possible keys, the key is a long random value with an astronomical number of possibilities, so guessing is not a practical attack.

The sequence is always the same, whatever the algorithm:

1. The data starts as plaintext: a login form submission, a database row, or a backup archive.
2. The sending or storing system runs it through the encryption algorithm using a key.
3. The result, ciphertext, is what travels over the network or sits on disk.
4. The receiving system (or your own system later) runs decryption with the matching key and gets the original data back, byte for byte.

Now, one thing that example doesn’t show: in a real system the hard part is almost never the math. The challenge is getting the key to the right party without an eavesdropper picking it up along the way and keeping it somewhere an attacker can’t reach. That problem is what the next two sections are really about.

What happens to your data when it’s encrypted?

Nothing is lost and nothing is added; the data is still all there, just unreadable. If you open an encrypted file in a text editor you’ll see what looks like random bytes. Encrypted output is typically close to the size of the original, plus a small amount of overhead for things the algorithm needs to store alongside it.

A few practical consequences follow from that, and they catch people out:

• Encrypted data can’t be used while it’s encrypted. Your application has to decrypt it to search, display, or sort it. That’s why “the database is encrypted” rarely means what people hope it means.
• The key becomes the data. If you lose the key, the ciphertext is gone for good. No support ticket recovers it. If you leak the key, the encryption stops mattering.
• Metadata often isn’t covered. File names, file sizes, which server talked to which, and how much data moved can all remain visible even when the contents aren’t.
• It doesn’t verify anything on its own. Encryption hides content. It’s separate mechanisms (signatures, certificates, authentication tags) that prove who sent the data and that it wasn’t tampered with in transit.

That last point matters more than it sounds. Secrecy and trustworthiness are different properties, and good protocols deliberately provide both.

Types of encryption: symmetric vs asymmetric

There are two broad families, and the clearest way to understand them is to watch them work together.

Symmetric encryption

Symmetric encryption uses one key for both encryption and decryption. Both sides share the same secret. It’s fast and efficient, which makes it the right tool for bulk data, such as a 2 GB backup archive or every byte of a page your server sends to a visitor. AES is the symmetric algorithm you’ll see named most often. Its weakness is obvious: both parties need the same key, and you can’t safely send a key over the same channel you don’t yet trust.

Asymmetric encryption

Asymmetric encryption (also called public-key encryption) uses a mathematically linked pair of keys. The public key can be handed to anyone; the private key never leaves its owner. Data scrambled with one of the pair can only be unscrambled with the other. RSA and elliptic-curve cryptography are the common examples. Asymmetric operations are slower and heavier, so they’re used sparingly for establishing trust, not for moving volume.

How TLS combines them

When a browser connects to your site over HTTPS, the two sides run a handshake before any page content moves:

1. The browser asks your server to identify itself.
2. Your server presents its TLS certificate. This certificate contains its public key and a vouching signature from a certificate authority the browser already trusts. This is the asymmetric part, and its job is authentication. It proves the server really is the one that holds the matching private key for that domain.
3. The two sides then run a key exchange to arrive at a shared secret for this connection only. Current TLS does this through a key-agreement step where both parties derive the same value without ever transmitting it.
4. That shared secret becomes a symmetric session key, and the rest of the conversation, including headers, form submissions, and page HTML, is encrypted with it.

So asymmetric encryption solves the trust problem and symmetric encryption does the heavy lifting. If you’ve wondered why your certificate matters so much when it never actually encrypts your pages, that’s the answer. It’s what lets the browser believe the key exchange happened with you and not with somebody in the middle.

For the mechanics of certificates on a protected site, see our guide How SSL Works with a Website Firewall.

Encryption in transit, at rest, and end-to-end

The same algorithms get described with different labels depending on where in a system’s lifecycle they’re applied. These three terms come up constantly in hosting documentation, and they protect against genuinely different things.

In transit means data is encrypted while it moves across a network. HTTPS, SFTP, SSH, and an encrypted connection between your application server and a remote database are all encryption in transit. It defends against anyone positioned along the path, such as someone sharing the coffee-shop Wi-Fi, a compromised network device, or an ISP-level observer. It stops protecting the moment the data arrives and is decrypted.

At rest means data is encrypted while stored, such as on a disk, in an object-storage bucket, or inside a backup archive. It defends against someone obtaining the storage itself: a stolen laptop, a decommissioned drive, or a downloaded backup file. Here’s the limitation people miss. Full-disk encryption on a running web server protects almost nothing against a web-based attack, because the server is booted, the volume is mounted, and your application reads and writes plaintext all day long. A webshell on that server sees the same decrypted data your site does.

End-to-end means only the two endpoints hold keys, and nothing in between, including the service relaying the data, can read it. Messaging apps are the familiar example. Standard HTTPS to your website is not end-to-end in that strict sense, since your server decrypts the traffic in order to do anything with it. That’s not a flaw; it’s what a web server has to do.

The short version is that in-transit encryption protects the journey, at-rest encryption protects the parked copy, and neither protects data while your application is actively using it.

Where encryption shows up on your website

Here’s where the theory turns into things you can check this afternoon.

1. TLS/HTTPS for visitor traffic. This is the one with the padlock. Without it, every login, every checkout field, and every admin session travels in readable form across whatever networks sit between your visitor and your host. Browsers now flag non-HTTPS pages carrying form fields, and search engines have long treated HTTPS as the expected default, so this is a trust and visibility issue as much as a technical one. Our walkthrough covers the migration, including the mixed-content cleanup that usually trips people up.
2. HSTS, so the encryption isn’t optional. An HTTPS site that still answers on HTTP leaves a window open: the very first request can be plain, and that’s enough for a downgrade attempt. HTTP Strict Transport Security tells the browser to refuse plain HTTP for your domain going forward. We cover the header, its directives, and its tradeoffs in What is HSTS: HTTP Strict Transport Security.
3. SFTP and SSH for your own access. Plain FTP sends your username and password across the network in the clear. SFTP and SSH wrap the same work in an encrypted channel, and SSH keys are both more convenient and harder to steal than a typed password. See Understanding FTP and SFTP and What is Secure Shell (SSH) & How to Use It.
4. Encrypted backups. A backup is a complete copy of your site and its database, including customer records, order history, user accounts, the works. If it’s sitting unencrypted in a publicly reachable folder or a misconfigured bucket, it’s a breach waiting to be indexed. Encrypt backup archives, store the key somewhere other than the server being backed up, and test a restore occasionally so you learn now rather than later that the key works.
5. Selective database field encryption. Some applications encrypt individual sensitive columns like payment tokens, API credentials, or identity documents, at the application layer. It’s worth doing for genuinely sensitive fields, with two caveats. You give up easy searching and sorting on those fields, and if the decryption key lives in a config file on the same server, an attacker who reads your files gets both halves. Key management is the whole ballgame.
6. WordPress salts and security keys. The long random strings in wp-config.php aren’t encrypting your database, and the name confuses a lot of people. WordPress uses them to protect the values stored in authentication cookies, so a stolen cookie can’t simply be replayed or forged. Rotating them invalidates every existing session and logs everyone out, which is precisely why rotating them is a standard step after a compromise. Our guide on generating WordPress salts & security keys has the procedure.

What encryption does not do

This is the section we’d most like site owners to read twice, because the most common encryption mistake isn’t a weak cipher. It’s believing the padlock covers more ground than it does.

Encryption doesn’t make a site secure

HTTPS protects data in motion. It does nothing about a vulnerable plugin, a SQL injection flaw, a weak admin password, an exposed staging copy, or a backdoor left behind from an earlier infection. A fully compromised site serves its malware over a perfectly valid TLS connection, and the browser shows the padlock the whole time.

Encryption is not hashing, and passwords should be hashed

Encryption is two-way by design; the right key reverses it. Password storage needs the opposite property. A hash is a one-way transformation with no key that undoes it; the system stores the hash, then hashes what you type at login and compares the results. Good implementations add a unique random salt per password and use a deliberately slow algorithm such as bcrypt or Argon2, so mass guessing is expensive. If a service can email you your existing password in readable form, it isn’t hashing them. Our post Password Security & Password Managers goes into what this means for the accounts you control.

Encryption is not obfuscation

Injected malware is often described as “encrypted”, but what our analysts usually find is obfuscation, such as base64 encoding, gzip compression, hex-escaped strings, or character arrays reassembled at runtime, layered to defeat casual reading and simple signature matching. There’s no secret key involved, which is why the layers can be peeled back and the payload read. It’s camouflage, not cryptography, and the practical lesson is that “I can’t read this code” is not the same as “this code is protected.”

Encryption doesn’t help once an attacker is authenticated

This is the limit that matters most in real incidents. An attacker with a valid admin session, stolen hosting credentials, or a webshell on your server is inside the trust boundary. They see data after decryption, exactly as your application does. Every encrypted channel and encrypted volume on the box keeps working perfectly and protects nothing from them. That’s why patching, access control, monitoring for unexpected file changes, and multi-factor authentication don’t go away once HTTPS is in place. Backdoors: The Hidden Threat Lurking in Your Website describes how that persistent access is typically established, and The Impacts of a Data Breach covers what follows when customer data is exposed.

Is encryption good or bad?

It’s a tool, and like most tools it has no moral position of its own. But the question gets asked honestly, so it deserves a real answer rather than a shrug.

For you as a site owner, encryption is good without any meaningful qualification. It protects your visitors’ logins and payment details, keeps your own credentials from crossing networks in readable form, limits the damage of a stolen backup, and is effectively required by browsers, payment processors, and data protection regulations. There’s no scenario where leaving your visitors’ traffic unencrypted serves them better.

Of course, attackers use encryption too. Ransomware encrypts victims’ files and sells back the key. Malware command-and-control traffic hides inside HTTPS alongside everything else, which is one reason network-level filtering alone can’t catch everything. So double-edged? Sure, but withholding encryption from legitimate users doesn’t stop criminals. Criminals do not need anyone’s permission to use published algorithms. Again, this has essentially no bearing on whether you should serve your site over HTTPS. You should.

Where to start if you’re reviewing your own site

Work through it in rough order of exposure:

1. Confirm your site serves every page over HTTPS, including redirects from www and non-www, and that no page loads scripts, images, or stylesheets over plain HTTP.
2. Check your certificate is valid, covers all hostnames you actually use, and renews automatically.
3. Add HSTS once you’re confident HTTPS works everywhere, starting with a short max-age.
4. Switch any remaining plain FTP access to SFTP, and move server logins to SSH keys.
5. Make sure backups are encrypted and stored off the web server. Keep the key somewhere separate. Run a test restore to confirm everything works.
6. Rotate your WordPress salts and keys if they’ve never been changed, or immediately after any suspected compromise.

Encryption is a narrow control that does its one job extremely well: it makes data unreadable to anyone without the key, whether that data is crossing a network or sitting in storage. Keep it in place everywhere it applies, treat key handling as the part that actually requires judgment, and don’t let the padlock stand in for the access control, patching, and monitoring that cover everything encryption was never meant to touch.

If you’d like a sense of how these pieces fit together on a live site, the SSL, HSTS, and SFTP guides linked above are the natural next stops.

Frequently asked questions

What do you mean by encryption?

Encryption means transforming readable data, called plaintext, into unreadable output, called ciphertext, using a mathematical algorithm and a secret key. Only someone with the correct key can reverse it and recover the original. The algorithms are public and well studied; the secrecy rests entirely on protecting the key.

What happens to your data when it is encrypted?

It becomes ciphertext. The same information is rendered unreadable and typically remains close to its original size. Nothing is deleted, but nothing can be searched, sorted, or displayed until it’s decrypted with the matching key. If you lose the key, the data is unrecoverable. If you leak the key, the encryption no longer protects anything.

Is encryption good or bad?

For a website owner, it’s clearly good for protecting visitor logins, payment details, your own credentials, and stored backups. Browsers and payment processors now expect it. Attackers also use encryption. Ransomware is the obvious case, but that doesn’t make protecting your visitors’ traffic any less worthwhile.

What are the main types of encryption?

Symmetric encryption uses one shared key for both directions and is fast, so it handles bulk data. Asymmetric encryption uses a public and private key pair and is used to establish trust. You’ll also hear encryption described by stage: in transit, at rest, or end-to-end, depending on what it protects.

How do I encrypt my phone?

Current iOS and Android devices encrypt storage by default once you set a passcode, PIN, or biometric lock, so the main step is setting a strong screen lock and keeping the operating system updated. Check your device’s security settings to confirm. For your website, the equivalents are HTTPS, SFTP, and encrypted backups.

Does an SSL certificate make my website secure?

No. A certificate and HTTPS encrypt data traveling between visitors and your server, which is important but narrow. They don’t patch vulnerable plugins, block SQL injection, strengthen weak passwords, or remove a backdoor. A compromised site serves malware over a valid HTTPS connection with the padlock showing normally.