Subdomain Finder

What Is a Subdomain Finder?

A subdomain finder is a lookup tool that answers one simple question: which hostnames exist under a domain? Large organisations run shop.example.com, mail.example.com, staging.example.com and dozens more, and those names rarely appear in public DNS zone files, so a normal DNS query will not reveal them. What does reveal them is the certificate transparency log. Every time a TLS certificate is issued for a hostname, that issuance is recorded publicly and kept as a permanent entry. This tool reads those public certificate records, collects every hostname ever issued a certificate under your domain, filters the list down to your exact domain, deduplicates it, sorts it alphabetically and shows it in a table you can copy and export.

The tool is free, runs in your browser and needs no account. You type one apex domain, click a button, and get back a clean list of subdomains with the date each name first appeared in the certificate records when you ask for dates.

Why and Who It Is For

Subdomains multiply quietly. Marketing launches a campaign page, a developer spins up a test instance, an old service keeps answering on a hostname nobody remembers, and years later nobody knows what is still attached to the domain. A subdomain list is the starting point for fixing that.

• Security researchers and penetration testers use it to map the attack surface of a target before a review. Forgotten staging hosts and admin panels are common findings.
• System administrators and DevOps engineers use it as an asset inventory check to confirm that only the hostnames they expect are attached to the domain.
• IT and brand teams look for unexpected or look-alike hosts connected to their own domain.
• SEO and marketing professionals discover sections of a site they did not know were publicly reachable.
• Journalists and investigators read public certificate records to understand the infrastructure of an organisation.
• Domain owners simply want to see what is hosted under a domain they own or manage.

How This Tool Works

The lookup runs in layers, and every layer is a public certificate transparency source.

Layer one is the primary source. The server asks crt.name for every certificate record matching your apex domain. When first-seen dates are requested the request also asks for dates, and the service reads the remaining quota header from the response and remembers it for an hour, so it always knows how much of the upstream allowance is left.

Layer two handles rate limits. If the primary source answers with a rate limit or access denied status, the request is retried up to three times with a rotated browser user agent and a different client IP header, then up to three more times through rotating outbound proxies when the proxy layer is enabled. Each direct request runs with a 30 second timeout and each proxy attempt with the same 30 second ceiling.

Layer three is the fallback. If the primary source still cannot answer, the tool queries crt.sh with a wildcard pattern for your domain and a 45 second timeout. When that works, the response tells you the data came from crt.sh. If every layer fails, you get a clear failure message instead of a blank page.

Cleaning happens next. Whatever comes back is lower cased, wildcard prefixes are stripped, names containing spaces or quotes are dropped, and any name that is neither the apex itself nor a name ending with a dot followed by your apex is discarded. Duplicates are removed and the final list is sorted alphabetically, so two sources returning the same name produce one row.

Caching keeps it fast. A successful result is stored on the server for 24 hours per apex, so a repeat lookup of the same domain returns instantly and never touches the upstream quota again. A failed lookup is remembered for 10 minutes, so an exhausted source is not hammered while it recovers. The browser keeps its own copy in local storage for 24 hours, keyed by the apex and the dates setting. When the page serves from that cache, the response time card simply says cached.

What the response contains. The API returns the apex, the source used (crt.name, proxy, crt.sh or none), the remaining quota when it is known, the total count, the list of subdomains with their first-seen values, and a human readable message. The page shows the two numbers that matter: how many subdomains were found and how long the lookup took.

Key Features

• Search any public apex domain from one input box, with a paste from clipboard button beside it.
• Optional first-seen dates column showing when each hostname first appeared in the certificate records.
• Layered sources: direct primary lookup, retried requests with rotated identity, proxy rotation, then a crt.sh fallback.
• Results filtered to your exact domain, deduplicated and sorted alphabetically.
• Summary cards for the number of subdomains found and the response time.
• Row badges that mark the apex itself versus a real subdomain.
• A copy button on every result row.
• CSV export with a first-seen column when dates are enabled, plus plain TXT export of the name list.
• 24 hour caching on the server and in your browser, so repeat lookups are instant and free of quota cost.
• Apex domain can be pre-filled from the page address, and pressing Enter runs the search.
• No account, no installation and no API key to request.

How to Use This Tool

1. Type the apex domain in the box: the bare registrable domain such as example.com. Use the paste button if you copied it from somewhere.
2. Switch on First-seen dates if you want the date column and a dated CSV export.
3. Click Find subdomains or press Enter. The spinner shows while the lookup runs.
4. Read the summary cards. The first shows how many names were found, the second shows how long the request took.
5. Scan the table. Each row carries an apex or sub badge, the first-seen date when dates are on, and a copy button.
6. Click CSV or TXT to download the current result set. The file is named after your domain.
7. Search another domain at any time. The same rules apply to each new query.

Limits and Rules

The tool search endpoint is rate limited to 60 requests per minute, which is far beyond normal interactive use. A separate public API route exposes the same search under a stricter limit of five requests per minute per IP. The input must be a valid hostname that contains a dot: protocols, paths and subdomain prefixes are rejected with a validation message telling you to enter a registrable domain such as namecheap.com.

Results depend entirely on public certificate transparency logs. A hostname that has never had a publicly logged certificate will not appear: internal only names, hosts on private networks and names that resolve only inside a VPN are invisible to this method. Names are only kept when they belong to the apex you searched, so a certificate record for another domain never leaks into your list.

When the primary source is rate limited, a lookup can fail for a short window. Failures are remembered for 10 minutes and the tool tells you to try again in a few minutes rather than retrying forever. Successful results are cached for 24 hours, so a domain looked up earlier today returns the cached list even if a new subdomain appears tonight. The dates come from the certificate records themselves and describe certificate issuance, not the moment a host went live. Use this tool for discovery and research on domains you are authorised to examine, and do not use the list to touch systems you do not own or have permission to test.

When to Use and When Not To

Use it before a security review to see what is exposed, during an audit to compare the live hostname list against your asset register, when you inherit a domain and need to know what runs under it, before a migration so nothing is left behind, and whenever a certificate expiry notice mentions a hostname you do not recognise.

Do not treat it as a complete inventory of internal infrastructure, because certificate transparency only covers names that received public certificates. It is the wrong tool for real time monitoring, since the intended rhythm is an occasional lookup rather than a polling loop. It cannot tell you whether a host is alive, what software it runs or whether it is vulnerable; it only reports names found in certificate records. For port scanning, service fingerprinting or vulnerability checks, use a dedicated tool you are authorised to run.

Frequently Asked Questions