Port List Checker

Port list:

Accepts comma, space, semicolon, or newline separators. Examples: 22, 80, 443, 8080-8082, udp/53, ssh, https.

Default protocol:

Use TCP for web/admin lists, UDP for resolver or telemetry lists, or TCP/UDP when a firewall rule needs both transports.

Review context:

Choose the context closest to the list you are cleaning so the service ledger gives useful next actions.

Service-name tokens:

Leave recognition on for pasted runbooks; switch to strict numeric mode when validating machine-generated lists.

Broad range threshold:

Use lower values for tight internet-facing reviews and higher values for large internal scanner batches.

ports

Review port input

{{ error }}

{{ result.targetText }}

{{ header }}	Copy
{{ cell }}
No {{ tab.label.toLowerCase() }} rows Enter valid ports or service tokens to populate this table.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Firewall requests, scanner notes, and incident tickets rarely arrive as a neat list of destination ports. One line may say 22/tcp, another may say https, and a scan export may mix service names, ranges, and status words in the same paste. Before that material becomes a firewall rule or a scan target, the important question is not only which numbers are present. It is which transport protocols they belong to, how wide the ranges are, and which entries deserve review before someone trusts the cleaned list.

Port numbers identify application-facing services inside transport protocols. TCP and UDP both use the numeric range from 0 through 65535, but they do not share the same traffic behavior. A DNS resolver commonly needs UDP 53, sometimes TCP 53, and a web listener usually needs TCP 80 or 443. Treating a bare number as both protocols can overstate exposure, while assuming every bare number is TCP can miss resolver, time, VPN, or telemetry traffic.

Destination port: The service port a client is trying to reach, such as 443 for a common HTTPS listener.
Protocol marker: A TCP or UDP cue such as tcp/443, 443/udp, T:22, or U:161.
Inclusive range: A span like 8000-8010 that includes both endpoints and every value between them.
Service alias: A human name such as ssh, dns, or postgres that can map to one or more conventional port/protocol pairs.

Clean port lists reduce two common review errors. The first is confusing a registered service name with proof of what actually runs on the host. A server can run a custom application on 443, a database can be moved away from its usual number, and hostile services can sit behind familiar ports. The second error is copying source-port evidence into a destination-port exception. High dynamic/private ports are sometimes valid listeners, but in logs they often represent temporary client-side ports that should not become inbound allow rules.

Diagram showing mixed port text parsed into TCP and UDP sets, then mapped to IANA bands and review cues.

A normalized list is a review aid, not an approval decision. It can show that 0-65535 is broader than intended, that 445/tcp or 3389/tcp needs strong justification, or that a range crosses into the dynamic/private band. The actual approval still depends on service ownership, source restrictions, host reachability, authentication, patch status, and whether the listener is supposed to be reachable in that environment.

How to Use This Tool:

Start with the original port evidence, then use the review cues to decide what must be corrected before copying target strings elsewhere.

Paste values into Port list, choose Browse, or drop a text-like file under 1 MB. Commas, spaces, semicolons, pipes, and new lines are accepted, so scanner exports and ticket text usually need little cleanup before parsing.
Choose Default protocol for numeric tokens that do not already include TCP or UDP. Use TCP for most web, database, remote-access, and admin listeners, UDP for resolver, time, telemetry, and VPN negotiation lists, and TCP and UDP only when bare numbers truly need both transports.
Set Review context before trusting severity. Internet-facing firewall or NAT keeps exposure warnings strongest, Internal firewall or segmentation policy focuses on owner and zone checks, and Scanner target or validation run softens findings that may be expected test scope.
Decide how Service-name tokens should be handled. Recognize common service names expands names such as ssh, dns, https, rdp, postgres, redis, and wireguard. Strict numeric ports only reports names as ignored input.
Adjust Broad range threshold when the default 1024 ports is too loose or too strict. Lower values catch smaller wide-range exceptions; higher values fit inventory and scanner batches where broad ranges may be intentional.
Run the check and read Review port input if it appears. Values above 65535, unsupported words, service names that do not match the selected protocol, and reversed ranges should be corrected or accepted deliberately.
Inspect Normalized Port Set for protocol, compressed range, count, IANA band, service hints, and source tokens. Then use Service Review to find duplicates, broad ranges, dynamic/private destinations, and cataloged service risks.
Copy from Target Strings only after the Port Band Map and warning cues match the intended scope. Use Normalize when you want the input rewritten as compact tcp: and udp: lines for another review pass.

If the summary still says Needs ports or no valid ports are found, remove copied log columns, enable service-name recognition, or confirm that the pasted numbers are destination ports rather than protocol IDs, source ports, or unrelated scan fields.

Interpreting Results:

The headline count reports unique numeric ports. A value that appears under both TCP and UDP counts once in that headline, while Normalized Port Set and Target Strings preserve the protocol split. When the transport matters, read the protocol-specific rows rather than the headline by itself.

Port List Needs Review means at least one high-signal service, broad range, dynamic/private destination, duplicate, or input issue deserves attention under the selected context. Port List Normalized means the current rules did not find stronger cues. Neither message proves that a host is reachable, that a listener is patched, or that exposure is justified.

Port list result cues and follow-up checks
Visible cue	Meaning	Follow-up
`Input clean`	No ignored-token or correction messages are currently shown.	Still compare the protocol grouping with the ticket, scanner plan, or firewall change request.
`duplicates` above `0`	Repeated protocol-port entries were collapsed.	Use the normalized rows for imports instead of the raw pasted text.
`dynamic/private` above `0`	At least one destination is in `49152-65535`.	Confirm those are intentional service ports, not temporary client source ports from logs.
`Broad input range`	A pasted range met or exceeded `Broad range threshold`.	Replace broad destination access with named service ports unless scanner or inventory scope justifies the span.
`Ignored token`	Text did not parse as a valid port, range, protocol marker, scanner status word, or recognized service name.	Correct the token, switch service-name recognition on, or remove copied text from another column.

Use severity as triage, not as a final risk label. A Critical database port in an internet-facing context should stop a change for review, while the same port in a controlled scanner run may be expected. Match the finding to source restrictions, actual listener ownership, and the purpose of the request.

Technical Details:

Port-list cleanup has to preserve four facts: the numeric port, the transport protocol, the range that produced it, and the source token that appeared in the pasted text. Losing any one of those facts can change the review. U:161 should stay UDP SNMP evidence, tcp/445 should stay a TCP SMB finding, and any should become visible as the entire numeric range instead of staying hidden as a word.

IANA groups port numbers into System, User, and Dynamic/Private ranges. These bands are not a safety rating, but they make review faster. Low numbers often identify infrastructure and legacy services, mid-range values often identify application and database listeners, and high dynamic/private values should be checked carefully when the list is supposed to describe destination services.

Formula Core:

Ranges are inclusive. If a range is pasted in reverse order, the endpoints are sorted before the count is calculated.

rangeCount = end - start + 1

A token such as 8082-8080 becomes 8080-8082, so the count is 8082 - 8080 + 1 = 3. Duplicate removal is stricter than the headline count: two copies of tcp/443 collapse into one protocol-port pair, while tcp/443 and udp/443 remain separate transport entries.

Transformation Core:

Port list parsing and normalization rules
Stage	Rule	Why it matters
Token cleanup	Text after `#` is ignored, common punctuation is trimmed, and scanner words such as `open`, `filtered`, and `tcpwrapped` do not become errors.	Copied scan lines can be reduced without flagging every non-port word.
Protocol selection	`tcp`, `udp`, `tcp/udp`, `T:`, `U:`, `/tcp`, and `/udp` override the default protocol. A `T:` or `U:` prefix can continue across later tokens on the same line.	Mixed scanner syntax stays grouped by transport instead of becoming one flat number list.
Accepted values	Whole-number ports and inclusive ranges from `0` through `65535` are accepted. `any`, `all`, and `*` expand to `0-65535`.	Wildcard input becomes a visible full-range finding.
Service aliases	Common service names expand only when recognition is enabled. Names that do not fit the selected protocol are reported as ignored.	Runbook text can be parsed, while strict review can force every entry to be numeric.
Compression	Ports are sorted, repeated protocol-port pairs are collapsed, and adjacent values are merged into compact ranges.	The same normalized set can feed compact protocol lines, an Nmap-style argument, nftables destination-port lines, CSV, and JSON.
Review cues	Invalid tokens, reversed ranges, duplicates, broad ranges, dynamic/private destinations, and cataloged services become review entries.	The cleaned target set carries correction and approval clues with it.

IANA Bands:

IANA port bands used by the checker
Band	Lower	Upper	Review meaning
Reserved	`0`	`0`	Usually a wildcard or special token rather than a normal destination listener.
System	`1`	`1023`	Common for infrastructure, identity, file sharing, mail, DNS, time, and management services.
User	`1024`	`49151`	Common for application, database, VPN, broker, datastore, and alternate web listeners.
Dynamic/Private	`49152`	`65535`	Worth checking in destination lists because these values often appear as temporary source ports.

Review Context Rules:

Review context effects on severity and recommendations
Context	Severity behavior	Recommendation emphasis
`Internet-facing firewall or NAT`	Cataloged service severity is kept as-is; broad ranges are High.	Remove broad exposure, restrict management and database services, and require strong source controls.
`Internal firewall or segmentation policy`	Critical cataloged services are reduced to High; broad ranges are Medium.	Confirm owner, zone, and source/destination scope instead of treating every internal service as public exposure.
`Scanner target or validation run`	Critical, High, and Medium catalog severities are reduced one step; dynamic/private findings become Low.	Keep ports only when they are in scope for the validation run and document why broad targets are needed.

Limitations and Privacy Notes:

This checker processes pasted text and selected files in the browser. It does not scan hosts, test reachability, inspect firewall policy, or confirm which service is actually listening behind a port number.

Service hints come from a local catalog of common ports and should be treated as review cues, not live discovery.
Files are limited to text-like input under 1 MB, and only parsed port evidence is carried into the result views.
Expanded JSON port arrays are omitted when the unique port count is above 2048, while compact ranges and summaries remain available.
Any copied scanner or firewall command should still be checked against the real host, zone, source range, and change record.

Worked Examples:

Mixed firewall request

Paste 22, https, udp/53, 8080-8082 with Default protocol set to TCP and service-name recognition enabled. The normalized set keeps TCP 22,443,8080-8082 apart from UDP 53, and the service review calls out SSH, DNS, and alternate web listeners for the selected context.

Broad range exception

A request containing 10000-12050 produces an inclusive count of 2051 ports. With the default broad-range threshold of 1024, Service Review flags the range so the reviewer can replace it with named destination ports or document why a wide scanner or inventory target is intentional.

Strict numeric cleanup

Switch Service-name tokens to Strict numeric ports only and paste ssh,443,redis. The result keeps 443 but reports ssh and redis as ignored tokens, which is useful when a machine-generated firewall import must contain only explicit numbers.

FAQ:

Does a service name prove the real service?

No. Names such as ssh, https, and redis are expanded as conventional review hints. Confirm the actual listener with host logs, socket tools, scans, or service inventory before approving access.

Why did one port appear under both TCP and UDP?

Some inputs or service aliases map to both transports, and TCP and UDP applies both protocols to bare numeric tokens. The headline counts the numeric port once, but the normalized table keeps separate protocol entries.

What should I do with ignored tokens?

Read the Review port input message and correct the original text. Common fixes are enabling service-name recognition, removing copied status columns, adding a missing protocol marker, or replacing unsupported words with numeric ports.

Can I use the target strings directly in a scanner?

Use them as a starting point. Check Target Strings, Normalized Port Set, and Service Review together, then make sure the scanner syntax, source range, and authorization match the actual test plan.

Glossary:

TCP: Connection-oriented transport used by many web, database, shell, mail, and management services.
UDP: Datagram transport commonly used by DNS, time, telemetry, VPN negotiation, discovery, and some media traffic.
IANA band: The port-number range grouping used for System, User, and Dynamic/Private ports.
Dynamic/Private port: A value from 49152 through 65535, often used for temporary client source ports but sometimes used by services.
Service alias: A recognized name that expands to one or more conventional port/protocol pairs.

References:

Service Name and Transport Protocol Port Number Registry, Internet Assigned Numbers Authority, last updated 2026-05-29.
RFC 6335: IANA Procedures for the Management of the Service Name and Transport Protocol Port Number Registry, RFC Editor, August 2011.
Port Specification and Scan Order, Nmap Reference Guide.
NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy, National Institute of Standards and Technology, September 2009.
How to check if a Linux service is listening on a port, Simplified Guide.
How to allow a port through the firewall in Linux, Simplified Guide.