Gobuster vs ffuf vs feroxbuster — Speed & Accuracy Benchmark 2026

Gobuster vs ffuf vs feroxbuster — Tool Overview

Before the benchmark, understand why three tools exist for what sounds like the same job. All three are written in Go, all use thread-based parallelism, all focus on web directory and resource discovery. Their differences reflect different philosophy about what a fuzzer should optimise for.

Gobuster prioritises simplicity and reliability. Clear syntax, predictable behaviour, minimal configuration. It does directory and DNS enumeration well. It doesn’t recurse deeply by default. It’s the tool you reach for when you want results in under two minutes without thinking about configuration. Pre-installed on Kali Linux. Stable. Fast enough for most cases.

ffuf prioritises flexibility. The FUZZ placeholder can appear anywhere in the HTTP request — URL path, query parameters, request body, headers. This makes it a general-purpose HTTP fuzzer rather than just a directory scanner. Parameter discovery, virtual host enumeration, API endpoint discovery, header injection testing — ffuf handles all of these with the same syntax. Its filtering system is the most powerful of the three. Slightly higher learning curve but the most versatile tool in the set.

feroxbuster prioritises completeness. Automatic recursion means it doesn’t stop at the top level — it queues discovered directories for their own scan immediately, building a complete map of the site’s directory structure without manual intervention. Its wildcard detection is the most automatic. Its output is the most detailed — showing the full discovered path hierarchy in real time. The tool of choice when thoroughness matters more than raw speed.

Speed Benchmark — Real Numbers

Speed benchmarks for directory fuzzers are consistently misunderstood in online comparisons. The raw requests-per-second numbers (ffuf fastest, feroxbuster second, gobuster third) reflect local network performance against a fast responding server. Against real internet targets, network round-trip time becomes the dominant factor — all three tools spend most of their time waiting for responses rather than processing them. On a target with 100ms response latency, the throughput difference between ffuf and gobuster shrinks to near-irrelevant levels.

Where speed differences are meaningful: large wordlists (SecLists Big.txt at 20,000+ entries), internal network assessments with low latency, and localhost scans. In these scenarios, ffuf’s higher thread efficiency produces a measurable advantage. For typical bug bounty internet targets with 50-200ms latency and a standard medium wordlist (4,600-10,000 entries), any of the three tools completes the scan in 1-4 minutes — a difference that rarely matters.

Wildcard Handling — The False Positive Problem

Wildcard responses are the primary source of useless output from directory fuzzers. A wildcard target returns a 200 OK response for every URL path — whether it exists or not. Some web frameworks return 200 with an error message embedded in the body. Some redirect all paths to a landing page with 301. Without wildcard detection, a fuzzer reports thousands of false positives that all look like legitimate discoveries.

feroxbuster handles this automatically: it sends requests for randomly generated non-existent paths before the main scan. If those return 200, feroxbuster fingerprints the response (size, word count, content hash) and automatically filters responses matching that fingerprint during the real scan. gobuster has basic wildcard detection but it triggers a manual prompt rather than automatic filtering. ffuf relies on manual filter configuration: you must identify the wildcard response size or word count and specify -fs [size] or -fw [wordcount] as filters before the scan is useful.

Recursive Scanning — feroxbuster’s Winning Feature

Recursion is the feature that matters most for thorough web reconnaissance. Non-recursive directory scanning only discovers paths one level deep from the starting URL. A target with the structure /admin/users/active/ requires three levels of recursion to discover — a flat scan finds /admin/ but misses /admin/users/ and everything below it. In real web applications, the most interesting content — admin panels, API endpoints, configuration files — is often nested several levels deep.

feroxbuster’s approach: when it discovers a directory (a 301 or a path that looks like a directory based on trailing slash), it immediately adds that directory to the scan queue and runs the full wordlist against it. The depth can be limited with --depth [n] to prevent infinite recursion on sites with generated URLs. gobuster’s -r flag enables recursion but the implementation is less automatic — it doesn’t always queue new directories immediately. ffuf’s -recursion flag works similarly. In practice, feroxbuster’s recursive output is typically 2-3× more complete than gobuster on complex targets with nested directory structures.

ffuf’s FUZZ Flexibility — Beyond Directory Scanning

ffuf’s defining capability is FUZZ placement. In gobuster and feroxbuster, the wordlist is substituted into the URL path. In ffuf, the FUZZ keyword can be placed anywhere in the HTTP request — the URL path, query string, POST body, or any HTTP header. This makes ffuf the only general-purpose HTTP fuzzer of the three, not just a directory scanner.

The Three-Phase Professional Recon Workflow

The debate “which tool is best” misses the point that experienced bug bounty hunters and penetration testers use all three tools in sequence, each filling the role it’s best suited for.

Phase 1 — Quick Surface Scan (gobuster): Start every new target with gobuster + small wordlist (4,600 entries). Completes in 1-2 minutes. Gives you a quick map of the obvious surface — admin paths, login pages, API prefixes, backup files. This informs what to pursue in Phase 2.

Phase 2 — Deep Recursive Scan (feroxbuster): Run feroxbuster + medium wordlist with –depth 3 against any interesting directories found in Phase 1. Let it run — this takes 10-30 minutes on a real target but discovers the nested structure that gobuster’s flat scan missed. Set it running and investigate Phase 1 findings while it works.

Phase 3 — Targeted Parameter and Header Fuzzing (ffuf): Once you have a map from Phases 1-2, use ffuf for specific targeted tests: parameter fuzzing on interesting endpoints, virtual host enumeration, POST body fuzzing against login and API endpoints. ffuf’s FUZZ flexibility handles everything Phase 1 and 2 can’t.