httpx Review

Subfinder finds potential targets. Httpx tells you which ones are live.

Httpx is the go-to second step in recon pipelines. A raw subdomain list is mostly speculative. Hosts are dead, or redirecting, or just noise. A few are worth inspecting. Httpx filters out the noise. You get a list of live hosts, with web server fingerprints.

The ProjectDiscovery workflow already includes tools like this. The questions are: How fast does httpx work? How much useful data does it collect in one pass? Can you scale the output?

What httpx Does

httpx probes HTTP hosts fast, returning status codes, page titles, response sizes. It also gets redirect behavior, content hashes, detected tech, web server headers, and fingerprints.

It answers the first big question after you enumerate hosts: which ones are up and what are they serving? On a big attack surface, it turns thousands of hostnames into a prioritized list of exposed web assets.

httpx reads from stdin and works with subfinder, Amass, assetfinder. No reformatting is needed; just pipe in hostnames and enrich the list.

The tool is fast, a Go binary with concurrency and rate limiting. It processes large lists in seconds or minutes. It is good for bug bounties and big enterprise recon; operators like that.

Key Flags and Output Fields

httpx tells you if a host responds. That's not all. You decide what extra info to gather. No bloat.

The tool offers several core flags: -status-code, -title, -tech-detect, -follow-redirects, -ip, -content-length. These cover triage. Status codes classify responses. Titles help spot login portals, admin consoles. Tech detection leads to targeted testing. IP addresses show shared hosting. Content length helps find repeated responses.

Balance is key. More fields provide richer output. But extra features add time and volume. When working with large host lists, choose flags wisely. An initial sweep with status codes, titles, and tech detection is a good start. Then, probe interesting targets in more detail.

JSON output makes httpx useful in workflows. With -json, fields are structured. You can pipe the output to jq, import it to a database, or feed it to downstream tools. This approach is better than parsing text.

The tool's probe features help reduce noise. Features such as wildcard DNS and parked domains can be filtered out. Content-hash comparison finds live but uninteresting hosts. This provides a fast way to shrink huge host lists. You can then focus on what matters.

httpx in the ProjectDiscovery Pipeline

The canonical pattern works:

subfinder -d target.com -silent | httpx -silent -status-code -title -tech-detect

This pipeline mirrors a typical engagement. You enumerate passively, then probe, and finally filter results into something actionable. For many targets, this one-liner yields enough information to find anomalies such as forgotten staging apps, third-party panels, misconfigured admin portals.

Status code filtering is key. A long list of 200 responses helps. But 401 and 403 responses are equally interesting. They point to access-controlled resources that might expose panels, APIs, or sensitive paths. Redirect chains reveal a lot. The repeated 302 behavior exposes SSO infrastructure or legacy migration paths.

The full pipeline showcases httpx's role.

subfinder → httpx → nuclei

That sequence works because each step shrinks the problem. subfinder spits out possible assets. httpx filters out the dead ones and labels the live ones. nuclei tests those surfaces for exposures. Without httpx, you're stuck scanning ghost servers or guessing which templates to run.

httpx is the sorting layer, making the rest of the stack efficient. Even if you don't feed nuclei right away, httpx still streamlines the process.

Practical Triage and Limitations

The most useful thing httpx gives you at scale is segmentation.

If tech detection shows a subset of WordPress hosts, those can move into CMS-focused checks. If titles reveal login panels, those become candidates for auth review, MFA assessment, or credential attack considerations where permitted. If the output exposes API gateways or developer portals, those hosts can move into parameter fuzzing, endpoint discovery, or schema-based review. Large attack surfaces become manageable not by looking at everything equally, but by grouping similar assets fast.

Content hash comparison is especially good for pruning waste. When dozens or hundreds of hosts return effectively identical responses, you are often looking at wildcard DNS, parked assets, shared error pages, or default infrastructure banners. Filtering those out early saves time and keeps the interesting outliers visible.

The limitation is straightforward: httpx is active. It makes HTTP requests, and those requests are visible to the target. It does not belong in purely passive phases or in situations where scope and authorization are not already clear. This boundary is between recon and touching the target.

There is a workflow limitation. Httpx can collect much in one pass. If you enable every useful flag on every large run, you can end up with slower scans, noisy output, and more data than you can realistically triage. The tool is strongest when you use it deliberately rather than treating it as a kitchen-sink scanner.

Verdict

httpx earns its place. It's the fastest way to turn passive discovery output into live targets. A prioritized web list, ready for testing.

The tool's value isn't just checking if a host is live. It's what you get alongside liveness: status codes, titles, tech stacks, redirects, hashes, all in a structured format. You triage quickly. Large attack surfaces are no problem. Simply feed the right hosts into the next test phase.

In the ProjectDiscovery workflow, httpx bridges the gap. You enumerate subdomains, then identify valuable web assets.

Already using subfinder and nuclei? httpx streamlines the process with key flags for status codes, titles, tech detection. You'll save time on the next big host list. It usually pays for itself immediately.