How to access WordPress files via FTP (and why you might not need to)

You need to get into the files behind your WordPress site – upload a theme, edit wp-config.php , replace a corrupted plugin, recover from a locked-out admin. The traditional answer is FTP. The modern answer is SFTP (FTP’s encrypted successor), and on most decent hosts you do not even need an FTP client at all – the hosting control panel has a browser-based file manager that does the same job with no setup.

This guide covers when you actually need a file-transfer client, how to set up SFTP correctly (always SFTP, never plain FTP), and when you should reach for a different tool instead.

Quick answer#

• For a one-off file edit or upload: use your hosting control panel’s file manager. No client, no credentials, no setup.
• For frequent file work or bulk transfers: use SFTP via FileZilla (or any SFTP-capable client). Port 22, your hosting username, password or SSH key.
• Never use plain FTP (port 21). It sends your credentials in clear text. Use SFTP or FTPS, not FTP.

If “FTP” is in your hosting documentation, vendor login, or troubleshooting guide, treat the word as shorthand for SFTP. Almost every host means SFTP when they say FTP today.

When you actually need an SFTP client#

Most WordPress tasks do not require one. The dashboard and the control panel cover plugin installs, theme uploads, media management, settings, and database edits (via phpMyAdmin or the panel’s database tools). SFTP becomes necessary in a small set of specific situations:

• The plugin or theme zip is too big for the dashboard. WordPress respects PHP’s upload_max_filesize for admin uploads. If you are uploading a 200MB premium theme on a host that caps uploads at 64MB, the dashboard will refuse it. SFTP bypasses that limit because the file lands on disk directly. (You can also raise the upload limit – see how to increase the maximum upload file size in WordPress.)
• You are locked out of wp-admin. A bad plugin update, a wrong redirect, a broken .htaccess , or a corrupted theme can lock you out of the dashboard entirely. You cannot install a fix-it plugin from a UI you cannot reach. SFTP lets you rename the broken plugin folder, restore the default theme, or edit the broken file directly. See locked out of WordPress admin: how to get back in for the full recovery playbook.
• You are migrating manually. A full-site migration involves moving wp-content/ plus the database. Hosting migrators automate this, but a manual migration is faster than waiting for a scheduled tool when you know what you are doing.
• You need to edit wp-config.php for debugging. Toggling WP_DEBUG , setting WP_MEMORY_LIMIT , or adding FORCE_SSL_ADMIN is a one-line change. The dashboard cannot edit wp-config.php . SFTP can.
• You are inspecting files for malware or corruption. Hashing core files, comparing them to the official WordPress release, or reading PHP error logs is faster from a terminal than through any UI. (See how Wordfence and similar plugins use SFTP-equivalent access for cleanup.)
• You are managing more than one site. Drag-and-drop in a control panel is fine for one site. For ten, an SFTP client with bookmarks and a left-right file pane is faster.

If none of these match what you are trying to do, the control panel file manager is almost certainly the better tool. See WordPress file manager: managing files without FTP for that route.

SFTP vs FTP vs FTPS: pick the right protocol#

Three protocols share the same family name. They are not interchangeable.

SFTP is the right answer for almost every modern hosting environment. It runs over SSH on port 22, which means the same firewall rule and the same authentication method as a normal SSH login. Reputable hosts disable plain FTP entirely. If your host still offers port-21 FTP, treat it as a legacy option and use the SFTP credentials they also provide.

For the deep comparison see SFTP vs FTP vs FTPS: which should you use. For the protocol-level explanation of how SFTP works, see what is SFTP and how does it work.

Setting up SFTP for WordPress (FileZilla, five minutes)#

FileZilla is free, runs on Windows/Mac/Linux, and supports SFTP out of the box. The setup looks the same in any other client – hostname, port, username, authentication.

What you need from your host

Before you open FileZilla, gather four things from your hosting control panel:

1. Hostname. Often your-domain.com , sftp.your-host.com , or a server-specific address like web123.your-host.com . Check your host’s docs – some require the IP rather than the domain during DNS propagation windows.
2. Username. Usually your hosting account username, or a per-site SFTP user the panel created for you.
3. Authentication. Either a password (set in the control panel) or an SSH key (preferred – see below).
4. Port. SFTP is port 22 by default. Some hosts use a non-standard port for security; check the docs.

If your host has a “create FTP account” or “create SFTP user” page, you can also create a scoped user limited to a single site directory. This is what you should give to a developer who needs file access to one site but not the whole hosting account.

Connecting from FileZilla

1. Open FileZilla and go to File > Site Manager > New site.
2. Set Protocol to “SFTP – SSH File Transfer Protocol”. This is the most important step. The default in FileZilla is plain FTP – change it.
3. Set Host to your hostname and Port to 22 (or your host’s custom port).
4. Set Logon Type to either “Normal” (password) or “Key file” (private key).
5. Enter your User and either the password or the path to your private key.
6. Click Connect.

On the first connection you will see a host-key fingerprint dialog. Verify it matches what your host published, accept it, and FileZilla remembers it for next time. A surprise fingerprint change later means either the host rebuilt the server or someone is intercepting the connection – do not blindly accept a changed key.

You now see your computer’s files on the left and the server’s on the right. The WordPress install lives somewhere like ~/public_html/ , ~/htdocs/ , ~/sites/your-domain.com/public/ , or ~/www/ . The exact path depends on the host. Look for wp-config.php to confirm you are in the right directory.

Use SSH keys instead of passwords

Password authentication for SFTP works, but SSH keys are better:

• Brute-force attacks against SSH passwords are constant. A 4096-bit RSA or Ed25519 key cannot be brute-forced.
• Keys can be revoked from the server side without changing every other login.
• You can have a different key per machine, so revoking your laptop does not break your desktop.

Most hosting control panels have an “SSH keys” section where you paste your public key. Generate a key with ssh-keygen -t ed25519 if you do not have one. The public key ( ~/.ssh/id_ed25519.pub ) goes to the host; the private key ( ~/.ssh/id_ed25519 ) stays on your machine.

Common WordPress operations over SFTP#

Once connected, the WordPress directory layout looks the same on every host. The four directories you will spend time in:

• wp-content/plugins/ – one folder per plugin. Renaming a folder here deactivates the plugin without needing wp-admin. Useful for the locked-out scenario.
• wp-content/themes/ – one folder per theme. The active theme is set in the database, so to force a fallback to a default theme you also need to know what default themes exist (twentytwentyfour, etc.) – or use the database, not SFTP.
• wp-content/uploads/ – all media. Useful for bulk uploads or recovering attachments from a backup.
• The site root – wp-config.php , .htaccess , wp-settings.php , index.php . Touch only what you understand. A typo in wp-config.php takes the entire site offline.

Editing wp-config.php safely

Three rules:

1. Download a copy first. Save it as wp-config.php.bak on your computer before you edit anything. This is your one-click recovery if you mistype something.
2. Edit locally, not on the server. FileZilla and most clients let you “View/Edit” a file, which downloads it, opens it in a local editor, and uploads it on save. That is fine. What you should not do is rely on the server-side text editor in some control panels for wp-config.php – inconsistent newline handling has corrupted files in the past.
3. Add new lines above /<em> That's all, stop editing! Happy publishing. </em>/ . Anything below that line is loading WordPress. Anything above it is configuration.

A typical debugging change:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

That writes errors to wp-content/debug.log without showing them to visitors. Remove it after debugging.

Replacing a corrupted plugin

The fastest fix when a plugin update breaks the site:

1. SFTP into the site, navigate to wp-content/plugins/ .
2. Rename the broken plugin folder (e.g. woocommerce to woocommerce-broken ). WordPress treats the plugin as missing and deactivates it on the next request.
3. Load the site or wp-admin. If it works, you confirmed the culprit.
4. Download the previous version of the plugin from the official source, replace the contents of the original folder, rename back. Or upload a fresh copy of the latest version – sometimes a corrupted update is the actual issue, not a regression.

The same pattern works for themes – rename the active theme folder and WordPress falls back to the most recent default theme. Make sure a default theme is installed first.

Editing .htaccess

WordPress writes .htaccess rules for permalinks. If yours is broken (custom rules conflicted with a plugin, a redirect chain points back at itself), the safe fix is to replace the entire file with the WordPress default:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Then go to Settings > Permalinks in wp-admin and click Save – WordPress regenerates the file with any extra rules from active plugins. (On nginx the file is ignored entirely; rules live in the nginx config instead.)

SFTP versus the alternatives#

The honest answer is that for most WordPress site owners, SFTP is the wrong default tool. It is overkill for one-off edits, slow for bulk media uploads if your connection is mediocre, and adds a credential set you have to manage.

The cleaner stack for most sites:

• Hosting control panel file manager for occasional file edits. Browser-based, no client, no credentials, works from a phone.
• WP-CLI for repetitive operations (plugin installs, search-replace, user management). Faster than any UI for power users. See how to install WordPress with WP-CLI.
• SFTP for the situations listed earlier – oversized uploads, locked-out recovery, multi-site bulk work, manual migrations.
• SSH terminal when you need to run commands, not just move files.

The “WordPress File Manager” plugin (and similar dashboard-based file manager plugins) is the option you should think hardest about. It runs inside WordPress with the same permissions as your wp-admin user, which means a single compromised admin account can read or modify any file – and that plugin family has shipped critical RCE vulnerabilities affecting hundreds of thousands of sites in the past. The control panel file manager is a strictly safer alternative.

How Hostney handles this#

Every Hostney plan ships with a browser-based file manager in the control panel – SFTP-equivalent access without an SFTP client, without managing per-site SFTP credentials, and without exposing wp-admin to a file-editing plugin. You can upload, download, edit, search, extract archives, and chmod files from any browser. For most one-off file work you will never need FileZilla.

When you do need a real SFTP client – bulk transfers, a deploy script, or another developer who works from a terminal – SFTP credentials are available from the panel. Hostney runs SFTP on the standard port 22 with both password and key-based authentication. Plain FTP on port 21 is disabled by default – the credentials sent in clear text on FTP are not a tradeoff worth offering.

For locked-out recovery, the file manager is also the answer most of the time: it works when wp-admin does not, and you can rename a misbehaving plugin’s folder in a couple of clicks.

Summary#

FTP in the WordPress world means SFTP today – port 22, encrypted, key-authenticated, run from FileZilla or any equivalent client. You need it for oversized plugin/theme uploads, locked-out admin recovery, manual migrations, and bulk file work. For everything else, the hosting control panel file manager is faster and safer because nothing extra is installed inside WordPress and no credentials are sitting in an FTP client. Pick the tool that matches the job, never use plain FTP on port 21, and prefer SSH keys over passwords whenever your host supports them.