Hey hackers — you want a google dorks list that's actually usable, not a raw gist dumped from 2017 or a "cheat sheet" buried under three course upsells and a PDF gate. This is the organized operator library: the top commands explained in one reference table, categorized dork collections ready to copy (exposed files, config leaks, directory listings, admin panels, debug logs, credential exposure), the 2026 operator-status breakdown so you know what still filters and what silently became a plain keyword, plus the construction grammar to forge your own. Companion to our SQL injection dorks collection — that one goes deep on one vertical; this one is the full toolbox.
TL;DR: A Google dork = Google advanced operators (
Why they exist as a category: Google's index is the largest corpus of publicly reachable web content ever assembled, and it indexes what pages say — including error messages, file paths, and configuration output that pages were never meant to advertise. Operators are just the query language for asking precise structural questions of that corpus. The "dork" vocabulary (from the old "Google Hacking Database" era) describes the reusable patterns — a good dork is a question that keeps answering every time you run it.
Quick history so the ecosystem makes sense: the discipline formalized in the mid-2000s through Johnny Long's Google Hacking Database work — a catalogued collection of productive query patterns that turned scattered tricks into a teachable practice. Exploit-Database still maintains the GHDB as a living reference, and the grammar barely changed since: what evolved is the vocabulary (new artifact types like
What a dork is NOT: it's not access, not exploitation, not intrusion. It's search syntax. The line that matters (expanded in the legal section and in the SQLi dorks guide's recon section): querying is observation of Google's index; acting on results beyond reading what's publicly indexed is where separate rules apply. Every dork on this page is a question. Questions are free.
Composition grammar in four rules: operators bind to the token immediately after them (no spaces after the colon); spaces between terms mean AND; quoted phrases match as units;
How to run this library: category-by-category, scoped when you have a target (
The distinction isn't philosophical — it's operational. Google already fetched, parsed, and stored the content you're reading; your query changed nothing about the target's systems. The moment you go BEYOND the indexed artifact (clicking into the application, fetching files directly, probing the exposed parameter), you've left the search layer and entered the target's infrastructure. Dork well inside the first box, and be deliberate and authorized about anything crossing into the second. That's the entire discipline — technical and legal — in one table.
The canary technique (your personal deprecation detector): whenever you suspect an operator, run it with a nonsense token —
, and a technical signature (error string, filename, config key, path pattern). Start with the tightest element, verify results, add one operator at a time, verify again — incremental construction beats all-at-once assembly every time. The SQLi dorks guide's "build your own" section has worked examples of the formula in action.
Go deeper with the series: the SQL Injection Dorks companion takes the same grammar into one vertical deep-dive — error signatures, parameter surfaces, the full workflow from query to report. Read both and the entire recon-dorking surface is covered: this page for grammar and breadth, that one for depth in the highest-signal vertical.
BlackSec channel: t.me/Blacksec_official — drops, tradecraft, community. Only official channel we run — anyone else wearing our name is running their own little operation.
Related boards:
— BlackSec crew. Operator status current for 2026. Google iterates syntax occasionally: when an operator on this page stops filtering, run the canary, update your notebook, and keep the library yours.
TL;DR: A Google dork = Google advanced operators (
inurl:, intitle:, filetype:, site:…) combined with keywords to query Google's index with surgical precision. The operator core still works in 2026 (with specific deprecations flagged below), the value lives in query design not list-copying, and everything here is passive — you're searching an index Google already built, which is the entire legal/traditional boundary discussion in one sentence. Start at the top-10 table, graduate to the construction grammar, keep a notebook.What Are Google Dorks?
Definition: a Google dork (formally "Google hack query") is a search string built from Google's advanced search operators and keywords, designed to surface pages matching specific technical conditions rather than ordinary topic relevance. Where a normal search finds pages about a subject, a dork finds pages that contain, expose, or are structured in a particular technical way — SQL errors in content, backup files in web roots, directory listings, config files, login endpoints, stack traces in logs.Why they exist as a category: Google's index is the largest corpus of publicly reachable web content ever assembled, and it indexes what pages say — including error messages, file paths, and configuration output that pages were never meant to advertise. Operators are just the query language for asking precise structural questions of that corpus. The "dork" vocabulary (from the old "Google Hacking Database" era) describes the reusable patterns — a good dork is a question that keeps answering every time you run it.
Quick history so the ecosystem makes sense: the discipline formalized in the mid-2000s through Johnny Long's Google Hacking Database work — a catalogued collection of productive query patterns that turned scattered tricks into a teachable practice. Exploit-Database still maintains the GHDB as a living reference, and the grammar barely changed since: what evolved is the vocabulary (new artifact types like
.env files and .git directories replaced older targets) and the noise level (as CMS footprints multiplied, exclusion discipline became half the skill). Twenty years on, dorking remains the rare recon technique that requires zero infrastructure, zero tooling spend, and zero target interaction — which is exactly why it never got replaced by anything.What a dork is NOT: it's not access, not exploitation, not intrusion. It's search syntax. The line that matters (expanded in the legal section and in the SQLi dorks guide's recon section): querying is observation of Google's index; acting on results beyond reading what's publicly indexed is where separate rules apply. Every dork on this page is a question. Questions are free.
Top 10 Google Dorks Commands
The PAA-favorite, answered as the reference table it deserves — these ten operators compose literally every dork you'll ever need:| # | Operator | Function | Canonical example |
|---|---|---|---|
| 1 | site: | Restrict results to one domain (or domain subtree) | site:example.com inurl:admin |
| 2 | inurl: | Match text appearing in the page URL | inurl:".php?id=" |
| 3 | intitle: | Match text appearing in the page title | intitle:"index of" "backup" |
| 4 | intext: | Match text appearing in page body content | intext:"database password" filetype:env |
| 5 | filetype: | Filter by file extension | filetype:sql "INSERT INTO" |
| 6 | ext: | Alternate extension filter (behaves differently at times — test both) | ext:bak inurl:".php" |
| 7 | "exact phrase" | Quoted strings match verbatim (spaces allowed inside) | "you have an error in your SQL syntax" |
| 8 | OR (uppercase) | Union — match either side | filetype:log OR filetype:txt "error" |
| 9 | -word | Exclusion — drop results containing the word | intext:"config" -wordpress -drupal |
| 10 | * | Wildcard substitute within quoted phrases | "username: * password:" |
OR must be uppercase (lowercase "or" is just a word). That's the whole syntax. Everything else is vocabulary — which keywords you point the operators at.Once the basics are automatic, these patterns separate productive queries from noisy ones:
Narrowing with stacked scopes:
Boolean unions for category sweeps:
Exclusion campaigns: generic terms drown in CMS/CDN noise.
Wildcard phrase probing:
Negative domain scoping:
The golden rule of composition: build queries bottom-up. Start with the tightest element (an exact error string, a specific filename), verify it returns sane results, then add ONE operator, verify, add another. Queries assembled all-at-once fail mysteriously; queries assembled incrementally always tell you which element broke.
Narrowing with stacked scopes:
site:target.tld filetype:env intext:"DB_PASSWORD" — scope + type + content, three axes at once. Each additional operator cuts the result space multiplicatively; two well-chosen operators often beat five sloppy ones.Boolean unions for category sweeps:
filetype:sql OR filetype:db OR filetype:bak "dump" — one query per category of artifact instead of one per extension. Keep OR-lists to three-to-four items; longer unions start silently degrading.Exclusion campaigns: generic terms drown in CMS/CDN noise.
-wordpress -drupal -wix -squarespace on nearly any recon dork materially cleans results. Build your standard exclusion block once, reuse it.Wildcard phrase probing:
"password: *" "user:" finds credential patterns where the actual value varies — the wildcard does the variable-holding so your phrase stays tight. Only works INSIDE quotes; wildcards outside quoted phrases do nothing.Negative domain scoping:
site:.pk -site:gov.pk style — country-code scope with sector exclusions. Useful for landscape research where you want a region minus its government/education noise.The golden rule of composition: build queries bottom-up. Start with the tightest element (an exact error string, a specific filename), verify it returns sane results, then add ONE operator, verify, add another. Queries assembled all-at-once fail mysteriously; queries assembled incrementally always tell you which element broke.
The Master List: Recon Dorks by Category
The actual library, categorized by what each family surfaces. Copy-paste ready, organized for scanning instead of scroll-past:1. Exposed Files & Backups
| Dork | Surfaces |
|---|---|
filetype:bak inurl:".php" | Editor/automatic backups of PHP source sitting in web roots |
filetype:sql "INSERT INTO" "password" | Database dumps with visible schema and data statements |
intitle:"index of" "dump.sql" OR "db.sql" OR "backup.sql" | Directory-listed SQL dumps by common naming convention |
filetype:csv "email" "password" "name" | Exported datasets (CRM/DB exports) left reachable |
filetype:xls OR filetype:xlsx "login" "password" | Spreadsheet credential/asset inventories |
filetype:env intext:"APP_KEY" OR intext:"DB_PASSWORD" | Application environment files — the modern crown-jewel leak |
filetype:log "error" "stack trace" | Application logs with stack traces and internal paths |
inurl:"backup" filetype:zip OR filetype:tar.gz | Archive backups exposed by naming habit |
2. Config, Git & Dev Artifacts
| Dork | Surfaces |
|---|---|
inurl:".git/config" "branch" | Exposed .git directories — full source history downloadable |
filetype:yml intext:"password" OR intext:"secret" | CI/CD and service config files (Ansible/Docker/compose patterns) |
filetype:ini intext:"password" OR intext:"pwd" | Legacy .ini configurations with embedded credentials |
inurl:".DS_Store" "index of" | macOS directory residue exposing complete file trees |
intitle:"index of" ".ssh" OR "id_rsa" | SSH material in web-reachable directories (rare, severe) |
filetype:conf intext:"password" "server" | Server configs (nginx/apache/app) with embedded secrets |
inurl:"/proc/self/environ" OR inurl:"/etc/passwd" | Classic LFI-adjacent exposures (path disclosure class) |
3. Directory Listings ("Index Of")
| Dork | Surfaces |
|---|---|
intitle:"index of" "parent directory" | The base directory-listing detection query — broadest net |
intitle:"index of" "/var/www" | Listings exposing server filesystem paths |
intitle:"index of" "uploads" filetype:php | Upload directories with executable content visible |
intitle:"index of" "wp-content" "backup" | WordPress content trees with backup artifacts |
intitle:"index of" ".git" OR ".svn" OR ".env" | Dev-residue sweep across the big three artifact types |
intitle:"index of" "mail" OR "inbox" filetype:eml | Exposed mail archives (sensitive correspondence class) |
4. Login Pages & Admin Panels
| Dork | Surfaces |
|---|---|
intitle:"Login" inurl:"admin" filetype:php | PHP admin login endpoints |
inurl:"/administrator/" intitle:"Login" | CMS admin consoles (Joomla-family path convention) |
inurl:"wp-admin" intitle:"login" | WordPress admin — the most-indexed login surface in existence |
intitle:"phpMyAdmin" intitle:"Login" | Database GUIs facing the internet directly |
inurl:"/wp-login.php" "remember me" | WordPress login by form-marker text |
intitle:"Dashboard" inurl:"panel" OR inurl:"console" | Generic control-panel dashboards by title convention |
5. Logs, Errors & Debug Output
| Dork | Surfaces |
|---|---|
intext:"Warning: mysql_fetch_array()" | Older PHP with display_errors leaking query structure |
intext:"Fatal error:" "inurl" OR "stack" | Uncaught exception output exposing paths and versions |
filetype:log intext:"password" OR intext:"token" | Logs containing live credentials/tokens (the high-value log class) |
intext:"ASP.NET" "Version:" "Error" | Framework error pages revealing version/build info |
inurl:"/storage/logs/" intext:"exception" | App-framework log directories (Laravel-style paths) |
site: prepended), global when doing landscape research. Log every query that returns something interesting with a one-line note — the notebook habit (expanded in the SQLi guide's workflow section) is worth more than any static list, because lists rot and your notebook tracks the live index.Google Dorking vs Google Searching (And vs Hacking)
Three terms people conflate, separated cleanly so your mental model stays honest:| Activity | What touches what | Status |
|---|---|---|
| Google searching | Query → Google's index → read result snippets/pages as published | Ordinary search, obviously fine |
| Google dorking | Precisely-formed query → same index → same published content | Same mechanism, better questions — observation only |
| Interacting with exposed findings | Downloading the exposed dump, accessing non-indexed paths, testing a parameter | Separate act, separate rules — authorization required |
Five Mistakes That Waste Beginners' Time
Patterns that clog first-month dorking efforts, so you skip them instead of learning them the expensive way:- 1. Unquoted multi-word phrases.
intext:database password leakedwithout quotes becomes four independent words (Google may match ANY of them anywhere) — results turn to mush instantly. Quote every multi-word signature:intext:"database password". This single fix improves first-week results more than any advanced pattern. - 2. Spaces after operator colons.
inurl: ".php?id="(space included) breaks operator binding — you've asked for an empty inurl plus a separate phrase. Operators glue to their tokens:inurl:".php?id=", no gap, ever. - 3. Scoping too late, cleaning too late. Beginners run global queries first, then wonder why 90% of results are unrelated spam sites. Lead with scope (
site:when you have a target) and your standard exclusion block (-wordpress -wix -squarespacefamily) — filters before volume, always. - 4. Trusting cache age. A dork result might reflect a state from months ago — errors since patched, files removed, domains expired. Result ≠ live condition. Read the freshness signals (covered practically in the SQLi guide's verification spoiler) before treating any find as current.
- 5. Collecting lists instead of building queries. Downloaded lists are someone else's snapshot of an index that changes weekly. The operators are stable; the keywords rotate with technology. Spend 80% of learning time on grammar and construction (tables + spoilers above), 20% copying — inverted from what most beginners do, and the ratio that produces practitioners instead of collectors.
2026 Operator Status: What Still Works
Lists die when operators die. Current status so your queries don't silently fail:| Status | Operators | What to do |
|---|---|---|
| Fully functional | site:, inurl:, intitle:, intext:, filetype:, "exact", OR, -exclusion, * (in-phrase) | Build freely — these are the load-bearing core |
| Functional but nuanced | ext: (behaves inconsistently vs filetype: at times), inanchor: (niche value), intitle: multi-word edge cases | Test each new pattern with a sanity query before trusting at scale |
| Degraded / legacy | related: (heavily reduced), cache: (unreliable UI access), various Google-hack-era specials (phonebook:, author: for web) | Don't build workflows on them; alternatives exist (manual cache access, search-by-domain for related) |
| Plain keywords now | Older operator names Google reclassified (loc:, info: partial) | If results look universal (nonsense term returns the same pages), the operator stopped filtering — verify with a canary query |
zxqvnonexistent: — and compare results to the operator with a real token. Identical = operator dead, it's just text now. Run the canary monthly if dorking is part of your regular workflow; Google doesn't send change notices.The maintenance habit that keeps a personal dork library current for years:
Weekly: run your top five daily-use dorks, sanity-check result counts against your historical baseline. A sudden result explosion usually means an operator lost filtering power (results got broader); sudden zero usually means Google changed matching behavior on your keyword pattern.
Monthly: the canary technique against your full operator set (30 seconds each), prune dead operators from your standard blocks, and test any new pattern you've read about before adding it to the library.
Per-engagement: when a dork produces a surprising result class (new artifact type you hadn't seen indexed), write down the EXACT string that found it the day you find it. The best dorks are discovered accidentally; the notebook is what stops accidents from evaporating.
Annual: re-read your exclusion blocks — CMS/CDN noise patterns change (new page builders, new hosting conventions appear, old ones fade). Your 2024 exclusion list is carrying 2026 dead weight.
The practitioners whose queries stay sharp for a decade aren't the ones with the biggest copied lists — they're the ones whose lists are self-pruned. Ownership beats size.
Weekly: run your top five daily-use dorks, sanity-check result counts against your historical baseline. A sudden result explosion usually means an operator lost filtering power (results got broader); sudden zero usually means Google changed matching behavior on your keyword pattern.
Monthly: the canary technique against your full operator set (30 seconds each), prune dead operators from your standard blocks, and test any new pattern you've read about before adding it to the library.
Per-engagement: when a dork produces a surprising result class (new artifact type you hadn't seen indexed), write down the EXACT string that found it the day you find it. The best dorks are discovered accidentally; the notebook is what stops accidents from evaporating.
Annual: re-read your exclusion blocks — CMS/CDN noise patterns change (new page builders, new hosting conventions appear, old ones fade). Your 2024 exclusion list is carrying 2026 dead weight.
The practitioners whose queries stay sharp for a decade aren't the ones with the biggest copied lists — they're the ones whose lists are self-pruned. Ownership beats size.
FAQ
What is a Google dork?
A search query built from Google's advanced operators (site:, inurl:, intitle:, filetype: etc.) combined with keywords, designed to surface pages matching specific technical conditions — exposed files, error messages, directory listings, config leaks — rather than ordinary topic relevance. It's the query language for asking precise structural questions of Google's index; "dorking" is just advanced search applied to technical recon.Are Google dorks illegal?
No — issuing Google searches is the most routine internet activity there is. Operators change query syntax, not the nature of the act: you're reading what Google already indexed from publicly reachable pages. The legal boundary sits at ACTION on results — accessing systems beyond published content, downloading data you're not authorized for, testing parameters without scope. Dorking itself stays on the search side of that line; cross it deliberately, with authorization.What are the top 10 Google dorks commands?
site: (scope), inurl: (URL text), intitle: (title text), intext: (body text), filetype: (extension filter), ext: (alternate extension), "exact phrase" (verbatim matching), OR (union), -word (exclusion), and * (in-phrase wildcard). The reference table near the top of this page shows each with a working example — those ten compose every dork in the collections below.How do I write my own Google dork?
Stack three elements: scope (site: or blank), location operator (inurl:/intitle:/intext:/filetype, and a technical signature (error string, filename, config key, path pattern). Start with the tightest element, verify results, add one operator at a time, verify again — incremental construction beats all-at-once assembly every time. The SQLi dorks guide's "build your own" section has worked examples of the formula in action.Is Google dorking still relevant in 2026?
Yes — the operator core (site, inurl, intitle, intext, filetype, quotes, OR, exclusions) is fully functional, Google's index still contains error text and exposed files, and platforms like Exploit-Database's GHDB still maintain dork collections as standard tooling. What changes at the edges: specific legacy operators degrade (status table above), noise levels shift with CMS conventions, and query craft matters more as low-effort queries drown. Relevance is stable; the required maintenance habit is the canary technique.Google dorking vs hacking — what's the difference?
Dorking is querying Google's index and reading published content — observation through a search engine. Hacking (in the legal/operational sense) involves accessing systems or data beyond what's published to you. The dork FINDS an artifact someone else already exposed; interacting with that artifact beyond reading the indexed page is the boundary where authorization requirements begin. Same page's three-way table covers the distinction properly.Do I need tools or software for Google dorking?
No. Everything on this page runs in a plain Google search box — the queries ARE the tool. Software layers (dork databases, query builders, automated samplers) exist for volume and organization, but they submit the same operator strings you can type manually. The advantage lives in query design and maintenance discipline (the notebook + canary habits), which no tool performs for you automatically.What is the Google Hacking Database (GHDB)?
The GHDB is the historical and still-maintained catalog of productive dork patterns, originally compiled by Johnny Long and now hosted within Exploit-Database's ecosystem. It organizes queries by category (exploits, vulnerabilities, sensitive files, and so on) and remains the canonical reference point for the practice. Treat it like a phrasebook: the entries demonstrate pattern classes worth understanding, and the best use is studying WHY each query works (which operator carries the signal, which keyword matches what artifact) rather than copy-running entries whose target keywords predate current technology.How do I organize and store my own dorks?
Any system you'll actually maintain beats any system that's theoretically optimal — but the structure that scales: one file (or notes database) with one dork per line, grouped by category headers matching your research areas, each entry carrying a trailing note (what it found, when it last worked, result-count baseline). The note column is the differentiator — a bare list rots silently, a list with baselines tells you when an operator or keyword pattern degraded. Add the canary-test date to each operator block monthly, and prune entries that return nothing three cycles running. Ownership discipline again: your notebook, your baselines, your pruning schedule.Where To Go From Here
You've got the top-10 operator reference, five categorized dork families (40+ copy-ready strings), the construction grammar with power patterns, the three-way boundary table, the 2026 operator-status breakdown, and the maintenance system. That's a complete dorking practice — not a listicle, a practice.Go deeper with the series: the SQL Injection Dorks companion takes the same grammar into one vertical deep-dive — error signatures, parameter surfaces, the full workflow from query to report. Read both and the entire recon-dorking surface is covered: this page for grammar and breadth, that one for depth in the highest-signal vertical.
BlackSec channel: t.me/Blacksec_official — drops, tradecraft, community. Only official channel we run — anyone else wearing our name is running their own little operation.
Related boards:
- General Hacking — this guide's home board: recon threads, dork discoveries, fingerprinting discussions (both dork articles live here — the series hub)
- Hacking Tools — where recon graduates to tooling conversations (authorized contexts, obviously)
- Courses — structured paths for the underlying skills: web architecture, stack fingerprints, why these artifacts exist to be indexed in the first place
— BlackSec crew. Operator status current for 2026. Google iterates syntax occasionally: when an operator on this page stops filtering, run the canary, update your notebook, and keep the library yours.