Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
SFTP vs FTP for WordPress: plain FTP sends your password as readable text. See what SFTP fixes, what it doesn't, and how to switch safely.
Use SFTP. Plain FTP is a security risk on any WordPress site.
FTP moves files between your computer and your server without encryption. SFTP does the same job inside an encrypted SSH connection. On WordPress, plain FTP exposes your login, and whoever holds that login can write files straight into your site.
Most guides stop at "switch to SFTP". Switching is right, but it only protects the connection. It doesn't protect the password saved on your laptop, and saved FTP passwords have been stolen from laptops for years.
The three names look alike, but they aren't versions of one tool.
FTP is the original, designed in 1971. It sends everything unencrypted. FTPS is FTP with TLS wrapped around it, the same encryption behind HTTPS. SFTP is a different protocol. It runs over SSH, the channel admins use to reach a server's command line.
FTP | FTPS | SFTP | |
|---|---|---|---|
Encryption | None | TLS on top of FTP | SSH |
Usual port | 21 | 21 or 990 | 22 |
Login | FTP account | FTP account | SSH account or key |
WordPress verdict | Avoid | Fallback | Use this |
For WordPress, use SFTP. If your host has no SSH, FTPS is a fair fallback, and plain FTP is the one to drop.
Nobody picked plain FTP out of carelessness. Hosts handed it out for years, old tutorials still teach it, and it works. It goes wrong in four ways, and the second is the one most guides skip.
FTP sends your username and password with no encryption. Anyone on the same network can capture them with basic packet-capture software, such as hotel Wi-Fi or any network you don't control.
FileZilla saves Site Manager passwords with no real protection unless you set a master password. Malware has gone after saved FTP logins since at least 2010, when Threatpost reported infections that harvested FTP logins from PCs and used them to plant code on sites. Current infostealers do the same. Sandbox reports show a Vidar sample reading FileZilla's configuration files and a Lumma sample harvesting FTP logins. Both families are among the ones we see most behind ClickFix attacks. Saved SFTP logins are just as exposed.
Login limits, two-factor authentication and firewall plugins all run inside WordPress. FTP bypasses WordPress entirely. On a client site we recovered this summer, the login logs were a wall of failed attempts from Argentina, Brazil, Japan, Italy and a dozen other countries. WordPress-level defences can see and stop that traffic. An FTP login goes straight to the server's files, so whoever holds one doesn't need your wp-admin password.
A standard FTP account can usually write to wp-content and wp-config.php. That login gets passed to a developer, then a freelancer, then whoever comes next, and nobody rotates it. The same client site had one admin login shared across a whole team, plus five orphaned administrator records dating back to around March 2025, more than a year before the attack. FTP logins age the same way, and there's no clean way to add 2FA to them.
SFTP fixes the first problem well. It helps a little with the others.
SFTP fixes | SFTP doesn't fix |
|---|---|
A login and files readable on the network | A saved password stolen from your computer |
Password-only logins, because SSH keys are supported | A leaked or reused password |
Too many people with full access | |
Old accounts nobody deleted |
A key with a passphrase does help with the saved-password problem, because a stolen key file is useless without it. SFTP also moves the target rather than removing it, since SSH gets probed constantly too. Use keys, and turn password login off if your host lets you.
Our security experts remove malware, fix vulnerabilities, and protect your site.
Sometimes WordPress asks for your FTP details when you install a plugin or run an update.
That prompt appears when WordPress can't write files on its own, usually because the owner of the files differs from the user PHP runs as. That's an ownership problem, not a permissions one, and our file permissions guide explains the difference.
Many tutorials tell you to hardcode FTP_USER and FTP_PASS in wp-config.php, which leaves your FTP password in a plain file on the site itself.
The better fix is to have your host correct the ownership. On hosts where PHP owns the files, setting FS_METHOD to direct in wp-config.php stops the prompt, though some hosts don't allow it.
Here's the switch in five steps.
Ask your host if SFTP or SSH is on. Managed hosts such as Kinsta and WP Engine run SFTP already. Some shared hosts make you switch SSH on first.
Create an SFTP or SSH user, or upload an SSH public key. Give each person their own account.
Choose SFTP in your client and use the port your host gives you. 22 is the default. Some clients start on FTP, so check that the address begins with sftp://.
Stop saving passwords in plain text. In FileZilla, open Edit > Settings > Interface > Passwords. Pick the master password option, or choose not to save passwords at all.
Test one upload and one download, then turn FTP off at your host and delete the old FTP accounts. Each host does this differently, so ask support if yours has no switch for it.
Turning FTP off matters more than it looks. If the door stays open, anyone who already holds the old login can still walk through it.
Switching protocols is one job. Cleaning up access is another.
Today. If a tool still needs FTP, require encryption (FTPS). Change the old FTP password in case you used it anywhere else. Delete the accounts of anyone who has left.
This week. Give each person their own account, limited to the folders they need. Put a passphrase on every SSH key. Download your client only from its official site and keep it updated, because trojanized copies of FileZilla have stolen FTP logins before.
When you can. Allow only your own IP addresses to reach SFTP. Turn off the file editor in the WordPress dashboard too, which we cover in our wp-config and .htaccess hardening guide.
Sometimes it was. Check before you clean anything.
Save the FTP or transfer logs first. Hosts usually rotate them, and you'll want the raw record before you start changing things. On cPanel hosts they normally sit in a logs folder in your home directory, though how much you get depends on the host.
Look for logins and uploads from IP addresses you don't recognise, activity at odd hours, and new .php files in your uploads or theme folders. Then match the log times against the modified times on those files. An upload that lines up with a file your scanner flagged is very likely your way in.
Timing tells you a lot even without logs. On the client site from earlier, the attacker's folder names carried Unix timestamps. Decoded, they showed two bursts of file drops eleven hours apart, which meant a script was running and no person was typing. We never found a single entry point there, so we treated every credential as stolen, FTP and SFTP logins included.
Sucuri published a case where a site was cleaned but nobody reset the FTP passwords. Five days later two FTP accounts uploaded new malware from a different IP address, and the site was infected again.
If the logs point to FTP, work through our hacked-site investigation guide, then follow the manual scan and clean steps. Change every FTP, SSH, control panel and database password once the site is clean. If you'd rather hand it over, that's what our malware removal service is for.
Use SFTP. That part is settled. The rest of the job is less tidy. A saved password on a laptop, an old account nobody deleted, and a login shared with people who've moved on all matter about as much as the protocol does.
If you're not sure who still has file access to your site, our WordPress security audit is a good place to start.
Plain FTP isn't. It sends your login and files unencrypted, and that login gives full write access to your site. Use SFTP, or FTPS if your host has no SSH.
No. FTPS is FTP wrapped in TLS and uses an FTP account. SFTP is a separate protocol that runs over SSH.
No. On a correctly set up host, WordPress writes files itself. A prompt for FTP details usually means the file ownership is wrong.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →
Your WordPress site was clean and updated, yet it got hacked anyway. Here's how one infected neighbor on shared hosting can take you down with it.
OWASP updated its Top 10 for 2026. Here's what each risk actually means for a WordPress site, ranked by what causes real hacks, not theory.
19 real signs your WordPress site is hacked, grouped by who notices first: you, Google, or your host. Each comes with the 2-minute check to confirm it.
Block unwanted IPs, countries, and regions in WordPress the right way — .htaccess, nginx, plugins, and Cloudflare, with a decision table for each.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
