Subnet and PortsWeb ports: 80, 443 and the usual alternatives
What the IANA registry records for these ports, and how to use them safely.
What IANA records
| Port | Protocols | Registered name | IANA description | Assignee | Reference | Note |
|---|---|---|---|---|---|---|
| 80 | tcp, udp, sctp | http | World Wide Web HTTP | IESG | [RFC 9110] | Defined TXT keys: u=<username> p=<password> path=<path to document> |
| 80 | tcp, udp | www | World Wide Web HTTP | IESG | [RFC 9110] | This is a duplicate of the "http" service and should not be used for discovery purposes. |
| 80 | tcp, udp | www-http | World Wide Web HTTP | Tim Berners Lee | n/a | This is a duplicate of the "http" service and should not be used for discovery purposes. u=<username> p=<password> path=<path to document> (see txtrecords.html#http) Known Subtypes: _printer NOTE: The meaning of this service type, though called just "http", actually denotes something more precise than just "any data transported using HTTP". The DNS-SD service type "http" should only be used to advertise content that: * is served over HTTP, * can be displayed by "typical" web browser client software, and * is intented primarily to be viewed by a human user. Of course, the definition of "typical web browser" is subjective, and may change over time, but for practical purposes the DNS-SD service type "http" can be understood as meaning "human-readable HTML content served over HTTP". In some cases other widely-supported content types may also be appropriate, such as plain text over HTTP, or JPEG image over HTTP. Content types not intented primarily for viewing by a human user, or not widely-supported in web browsing clients, should not be advertised as DNS-SD service type "http", even if they do happen to be transported over HTTP. Such types should be advertised as their own logical service type with their own DNS-SD service type, for example, XUL (XML User Interface Language) transported over HTTP is advertised explicitly as DNS-SD service type "xul-http". |
| 443 | tcp, udp, sctp | https | http protocol over TLS/SSL | IESG | [RFC 9110] | |
| 8080 | tcp, udp | http-alt | HTTP Alternate (see port 80) | Stephen Casner | n/a | |
| 8443 | tcp, udp | pcsync-https | PCsync HTTPS | n/a | n/a | |
| 8000 | tcp, udp | irdmi | iRDMI | Gil Shafriri | n/a |
What the registry says
The table lists what the IANA port registry records for each port. Ports 80 and 443 are the defaults that browsers use when an address has no port: http:// means 80 and https:// means 443.
How to use them
- Port 80 (HTTP) carries unencrypted web traffic. Most sites now keep port 80 open only to send visitors to the HTTPS version.
- Port 443 (HTTPS) carries web traffic inside TLS encryption. This is where sites should serve their pages.
- Ports 8080, 8443 and 8000 are not defaults but are commonly chosen for a second web server, a test version, an admin panel or a proxy, because they are above 1023 and do not need special rights to open on many systems.
Safe habits
- Serve real sites over 443 with a valid certificate, and redirect 80 to 443.
- Do not leave admin panels and test servers on 8080 open to the internet. Restrict them by address or put them behind a login and HTTPS.
- If you change a port, say so in the address:
https://example.com:8443/. - A firewall rule for "web" needs both 80 and 443 in most cases.
Troubleshooting
If a page does not load, check that the server is listening on the expected port, that a firewall (on the server and in the network) allows it, and that you use the right scheme (https for 443). A browser message about a "secure connection failed" on port 80 usually means you used https:// against a plain HTTP port.
This is an independent guide. It is not connected with IANA, the IETF or any network equipment maker. Address and port data come from the IANA registries as fetched on 14 November 2026; RFC texts were read from rfc-editor.org. Check the originals for anything you rely on.