FTP Port: What Port Does FTP Run On?

If you searched "FTP port" and want the answer in one paragraph: FTP uses port 21 for the control connection and either port 20 (active mode) or a server-assigned ephemeral port (passive mode) for the data connection. SFTP uses port 22 — it's an SSH subsystem, not actually FTP. FTPS uses port 990 for implicit TLS or port 21 with a STARTTLS upgrade for explicit TLS. That's the whole answer; the rest of this post explains the why and the firewall implications.

FTP port numbers at a glance

Protocol	Port	Notes
FTP — control connection	21	Login, directory listing, transfer commands
FTP — data connection (active mode)	20	Server initiates the connection back to the client
FTP — data connection (passive mode)	ephemeral	Server opens a high-numbered listening port; client connects to it
FTPS — implicit TLS (control)	990	TLS handshake before any FTP commands. Legacy.
FTPS — implicit TLS (data)	989	Paired data port for implicit FTPS active mode
FTPS — explicit TLS	21	Plain start, client issues AUTH TLS to upgrade
SFTP	22	Runs inside an SSH session; same port as SSH

The four port numbers everyone needs to remember are 20, 21, 22, and 990. Everything else — passive port ranges, alternative SSH ports, custom-deployment ports — derives from those four.

Why FTP needs two ports

This is the part most people skip past, but it explains every weird FTP firewall problem you've ever had.

FTP was originally specified in RFC 959 (1985), with predecessors going back to 1971. The protocol was designed for a network where every host had a public IP, every host could accept inbound connections, and firewalls didn't exist. In that environment, separating control (commands like "log me in," "give me a listing," "send me this file") from data (the actual file bytes) made architectural sense — the two streams have different latency characteristics, and decoupling them let the protocol issue more commands while a large transfer was already in flight.

The original dual-port design — active mode — works like this:

1. Client opens a TCP connection from a random high port to the server's port 21. This is the control connection.
2. Client sends FTP commands (USER, PASS, LIST, RETR, etc.).
3. When a file transfer is needed, the client tells the server "send me the data on my port X." The client is listening for an inbound connection on port X.
4. Server opens a new TCP connection from its port 20 to the client's port X. The file bytes flow over this connection.

That worked fine when client hosts were directly reachable. It broke when NAT and firewalls became universal: the server's inbound connection in step 4 gets blocked by the client's firewall, and the data transfer never starts.

Passive mode is the fix. The handshake inverts:

1. Client connects to server's port 21 (control). Same as before.
2. Client sends PASV to ask for passive mode.
3. Server opens a new listening port on a high ephemeral port (somewhere in the 49152–65535 range by default, but every server lets you configure this) and tells the client "connect to me on port Y."
4. Client opens the data connection outbound to the server's port Y.

Both connections are now outbound from the client. Firewalls allow it. This is why every modern FTP client defaults to passive mode and why "active vs passive" is rarely a configuration choice you have to make anymore.

What this means for your firewall

If you're running an FTP server, you need to open:

• Inbound TCP 21 — the control port
• Inbound TCP range for passive-mode data ports. Most servers let you set this range (e.g., 49152–65535, or a tighter custom range like 50000–50100). Whatever you configure on the server, open the same exact range on the firewall. If the ranges don't match, the data connection silently fails and your users see "421 Service not available" or "MLSD aborted."
• Inbound TCP 20 — only if you support active-mode clients. Most modern deployments skip this.

If you're running an FTP client (or troubleshooting one), you need:

• Outbound TCP 21 — almost certainly already allowed by your network
• Outbound TCP to the server's passive-mode port range. Established-connection outbound is allowed by default on every modern firewall, so this usually requires no special configuration.

The classic FTP firewall failure pattern: control connection succeeds, login works, directory listing hangs. That's the data connection failing. Either passive mode isn't enabled on the client (try toggling), the server's passive port range isn't open on its firewall, or there's a NAT in the path that's mangling the IP address the server is advertising in its PASV response.

FTPS vs SFTP: very different protocols, confusingly similar names

The "secure FTP" name space has two protocols that look the same on the wire but are completely different underneath.

FTPS is FTP wrapped in TLS. The protocol semantics are identical to plain FTP — same commands, same dual-channel control/data structure, same active/passive modes — but the connections are encrypted. Two flavors:

• Implicit FTPS (port 990 for control, port 989 for data): TLS handshake happens before any FTP commands. Specified by Microsoft in the late 1990s; most modern deployments consider it deprecated.
• Explicit FTPS (port 21 for control, dynamic for data): Client connects to plain port 21, then issues AUTH TLS to upgrade the connection to TLS. The data connection also gets a TLS handshake before any bytes flow. This is the modern FTPS standard.

SFTP is not FTP at all. It's a file-transfer subsystem of SSH, defined in the SSH-2 protocol family. SFTP runs entirely inside an SSH session over port 22:

• Single port (vs FTP's two-port headache)
• Encrypted by default (vs plain FTP's cleartext + FTPS's optional encryption)
• Key-based authentication available (vs FTP's password-only model)
• Trivial to firewall (one outbound port; no active vs passive)

If you're choosing between FTPS and SFTP for a new deployment in 2026, SFTP is almost always the right answer.

The modern way: stop thinking about ports

In 2026, the "what port does FTP run on" question is most often asked by an admin debugging a misconfigured firewall on a self-managed FTP server. Passive port ranges, active-mode firewall callbacks, FTPS cipher negotiation, SSH host-key management — the friction of running FTP infrastructure is the main reason most teams have moved off self-managed servers entirely.

The modern answer: a hosted managed-file-transfer platform handles every port question for you.

Files.com is the File Orchestration Platform we'd recommend for any team running FTP-shaped workflows. You point your FTP clients at a subdomain Files.com provisions, and the platform handles the rest:

• SFTP (port 22), FTP (21), FTPS (21 + 990), and WebDAV all on one platform. Each protocol exposed on its standard port; your trading partners connect with whatever client they already use.
• Passive mode auto-configured. No port ranges to open on your firewall. Files.com manages its end of the data-channel choreography.
• Automatic TLS. Certificates provisioned and renewed automatically via Let's Encrypt; modern cipher suites by default. No FTPS cipher debugging.
• Per-user credentials, SSH key auth, audit logging, MFA, share links. All the things FTP alone never gave you, layered on top of the protocols it does give you.
• A real web UI on the same files. Same files exposed via FTP/SFTP are also accessible through a modern browser interface — drag-and-drop uploads, share links with passwords and expiry, the works.
• Beyond the protocols: REST API, AS2 partner messaging, automation workflows, SOC 2 Type II and HIPAA-BAA out of the box. The things FTP infrastructure was never designed to do.

That's a more honest shape for 2026 than running an FTP server yourself. Start a free Files.com trial — no credit card, provisioned in about 10 minutes.

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter (air-gapped environments, strict data-residency mandates, regulated industries), the free ExaVault on-premise appliance handles SFTP / FTP / FTPS / WebDAV from a self-hosted VM image.

FAQ

Should I use active or passive mode?

Passive. Always. Active mode requires the server to initiate a connection back to the client, which fails through almost every modern firewall + NAT setup. Every FTP client released in the past 20 years defaults to passive; many don't even surface an option to switch. If a vendor is asking you to enable active mode, push back.

Is port 21 secure?

No. Plain FTP — on port 21 or any other port you configure — sends usernames, passwords, and file contents over the network in cleartext. Anyone on the network path between the client and server can read everything. For anything sensitive, use SFTP (port 22) or FTPS (port 21 with explicit TLS).

What port does SFTP use?

Port 22. Same as SSH. SFTP isn't actually FTP — it's a subsystem of the SSH protocol that runs inside a regular SSH session, so it uses SSH's port. Some deployments run SSH on a non-standard port (port 2222 is common); in that case SFTP follows whatever port the SSH daemon is on.

What's the difference between port 20 and port 21 in FTP?

Port 21 is the control port — login commands, directory listing, transfer setup, all the metadata. Port 20 is the data port for active-mode connections — the actual file bytes flow over a port-20 connection that the server initiates back to the client. In passive mode (the modern default), port 20 isn't used; the data connection uses a high ephemeral port the server picks instead.

Can I run FTP on port 80 or 443?

Technically yes — most FTP servers let you set the control-connection port to whatever you want. But it doesn't help. FTP still needs its control port plus its data port(s); putting control on 443 just creates a conflict with HTTPS, and deep packet inspection still identifies the traffic as FTP regardless of the port. If your goal is "punch FTP through a strict outbound-only firewall," tunneling SFTP over an outbound HTTPS connection (with an SSH-over-HTTPS proxy) is the more honest answer.

Can I change FTP's default port?

Yes. Most FTP servers let you configure both the control-connection port and the passive-mode port range. Doing this for security ("port 21 is too well-known") doesn't actually buy much — port scanning makes this kind of obscurity ineffective — but doing it because port 21 is in use, or your network policy requires it, is fine. Just remember to tell your clients which port to connect to; FTP has no auto-discovery.

Why does my FTP client say "421 Service not available"?

The 421 response means the server can't accept the requested operation — almost always because the control connection succeeded but the data connection couldn't establish. Common causes:

• Firewall blocking the passive-mode data port range (most common — server's passive range and firewall rule don't match)
• Server hitting a concurrent-connection limit (too many users at once)
• TLS / FTPS misconfiguration (cipher mismatch, expired certificate)
• Stale session — try disconnecting and reconnecting

If you control both ends, run the client with verbose logging on; the actual error usually shows up in the first 10 lines of the protocol exchange.

What's the FTP port range for passive mode?

There's no fixed range — each server administrator picks one. The default on most servers is the IANA-registered ephemeral range (49152–65535), but tight production deployments usually narrow this to a specific block like 50000–50100 so the firewall rules stay manageable. Whatever range the server uses, the firewall in front of it must allow inbound connections on the same exact range.