GDorks: a plain text corpus of 320+ Google dork categories

GDorks ships dork text files, not an automated scanner

The problem GDorks addresses is narrow and familiar: writing Google search operators from scratch for every reconnaissance task is slow, and the syntax is easy to get wrong. A query that combines intitle with filetype or site can be typed in seconds, but composing a useful one demands the same operator knowledge each time. The repository answers that by collecting more than 320 categories and what the README describes as more than 3M dorks into plain text files that can be read, searched and pasted into a browser window.

The audience is people who already know what a search operator is. The project topics list bugbounty, ceh, osint, sqli and xss among others, which places it in the learning and reconnaissance crowd rather than in the software development crowd. What it is not is a tool that scans or attacks anything. It never contacts a target host, never authenticates against one, and never hands you a finding in a machine readable form. Every entry it offers is a starting string for a search you run yourself, and the quality of the result depends on the search engine sitting on the other end of the paste.

Directory names carry the taxonomy, file names carry the volume

The repository is organised as a set of directories named after vulnerability classes and content types, each holding one or more text files plus a README, with a large set of loose files at the top level. The documented layout looks like this.

  - Dorks(1M)/
    - README.md
    - Split #1.txt
    - Split #2.txt
    - Split #3.txt
  - More-Dorks/
    - README.md
    - 7k.txt
    - best2.txt
    - Amazon10k.txt
    - Gaming.txt
    - Shoping.txt
  - SQLi/
    - README.md
    - Sqli2.txt

The top level of the repository also lists CCTV/, Joomla/, Laravel/, Netflix/ and RFI/ directories, alongside files named dorks.txt, dorks.json, dorks2.txt, dorks3.txt, dorks-2023.txt and dorks4-category .txt. The naming is informal and in places inconsistent, and the trailing space in dorks4-category .txt is exactly as it appears in the file listing. A practical lookup therefore runs like this: pick the directory for the class you care about, open one of the text files inside it, and copy a line. The directory README files presumably explain each folder, and the large file names in parentheses suggest a split of a bulk set across numbered chunks.

The operator glossary is where the technique actually lives

Between the corpus and the raw text, the README carries a glossary of the Google search operators the entries rely on. It documents intitle for keywords in a page title, inurl for keywords in a URL, intext for keywords in page body, filetype for narrowing by extension such as pdf, doc or csv, ext for a specific extension such as php, and site for restricting the search to one domain. It also lists cache for a stored copy of a page, link for pages pointing at a given URL, related for pages related to a URL, and three information operators: define, info, and book.

That vocabulary is the durable part of the project, more so than any individual dork string. It is a compact, correct reference for the query syntax that the bulk files assume the reader already knows. Two practical notes follow from the design. First, the operators belong to one search engine, so a query that behaves one way on Google does not carry over to another engine, and a dork tuned around a particular operator will degrade quietly rather than erroring out when the engine changes its handling. Second, the glossary mixes content discovery operators with disclosure oriented ones, which is why the same syntax serves a researcher looking for publicly indexed documents and a tester looking for exposed endpoints. The README does not separate the two, so the reader inherits that judgement call.

A first session is copy, paste, read the results

There is no installation to perform. The README documents no package manager entry, no requirements file and no command, and the top level of the repository contains only text files, documentation and licence text. The intended routes are two. One is the hosted web application, which the README links as a live demo, and the project homepage is listed separately as https://gdroks.ishanoshada.com. The other is the repository itself, read directly on the hosting service or fetched with a version control client.

The web application flow the README describes has three steps. You open the demo, you select a category such as CCTV or SQL Injection, and you choose how many dorks you want pulled from that category, after which the app hands you random entries. That random draw is the point of the interface: rather than browsing thousands of lines, you take a small sample, test whether that category is productive, and keep pulling until you find a useful one. The README points to a separate GDorks-web repository for the code behind that app.

For a first real use without the web app, open a category directory, read a text file, copy a single line into the Google search field, and inspect what comes back. Expect to iterate on the query yourself. A dork that returns nothing usually needs a wider operator, a different keyword, or the removal of a term, and none of that work is automated for you.

The corpus ships without validation, provenance or a way to automate it

Several practical limits show up in what the repository does not provide. There is no timestamp per entry, no source attribution for where a query came from, and no record of when it was last confirmed to return results. Over time that means the file set will contain entries that no longer work, queries that duplicate each other across the numbered split files, and strings whose behaviour depends on regional or personal search settings. The presence of both dorks.json and several numbered dorks files with overlapping names suggests the same content exists in more than one shape, and nothing in the layout deduplicates it.

There is also no programmatic surface. The README points to a separate web application repository but does not describe an HTTP API, a command line entry point, or a schema for dorks.json beyond showing that the file exists. If your workflow needs to feed thousands of queries into a scanner, a log parser or a tracking sheet, you are left with reading the text and doing the plumbing yourself. Bulk use is also where the legal and ethical boundary sits: these are search strings, and running them against infrastructure you have no permission to test is not a technical question the project answers.

Searching through Google rather than through a private index

The design decision that defines GDorks is that it does not maintain its own index. It supplies queries, and Google supplies the corpus of results. The alternative model is a hosted dork database that crawls and stores matches itself, which can offer instant lookup against pages it has already seen and can expose historical entries that no longer rank. The trade runs in the opposite direction from what people usually expect. A self maintained index is fast and searchable but goes stale, and it is only as good as the crawl that filled it, while a list of queries always returns live engine output that reflects the current web, at the cost of being slower, subject to rate limiting, and sensitive to how the engine personalises and filters results for the person running the query.

The other difference is one of scope. A private index can store result metadata such as titles, hosts and dates, so you can filter and sort. GDorks stores queries alone, which means every fact you learn about a result comes from what Google decides to show you in the browser. The glossary in the README covers operators such as link, related, cache and info that are there precisely to widen that view, and the film and book operators are a different kind of entry entirely, aimed at content discovery rather than exposure.

A push on 2026-10-08, but the only tagged release is 1.2.1 from 2025-01-18

The repository is not archived and the last push was on 2026-10-08, so the files are being touched in the recent past. The only release listed is version 1.2.1, dated 2025-01-18, which means the work that landed after that tag is not distributed as a named version, and there is no changelog in the file listing to explain what changed. For a text corpus that distinction matters less than it would for a library, but it does mean there is no supported upgrade path and no stable artefact to pin. Taking an update means taking the current file state, and keeping your own copy of the text files is the only way to preserve a known good set.

Licensing is the simplest part of the picture. The project uses the MIT licence, a permissive grant that allows copying, modification, distribution and use in commercial work, provided the copyright notice travels with the material. That makes it straightforward to fold the dork text into an internal checklist or a scanning workflow. It does not grant any right over the systems the queries point at, and it says nothing about whether a given query is currently useful. The README also asks for support and donations, and the project links related work by the same author. Confirming the licence text in the repository file before redistribution is the sensible step, and treat it as permission to reuse the text, not as permission to run the queries.

Editorial conclusion

GDorks fits a bug bounty hunter or OSINT researcher who wants a searchable pile of ready made queries and is willing to verify each one by hand, and it does not fit an engineer who needs a repeatable, audited or automated finding pipeline. Before relying on it, paste a sample of the entries you intend to use into Google yourself and confirm the operators still behave as the README describes, and check that your use of the queries stays inside systems you are authorised to test.

Frequently asked questions

Official sources

1. Ishanoshada/GDorks on GitHub
2. License: MIT
3. Project website
4. README
5. Releases