- Does this run on the server?
- No. Every template lives in the page's JavaScript bundle and the merging happens in your browser. We don't upload your choices, we don't log them, and we don't store them. Refresh the page and the slate is clean.
- Which technologies are supported?
- Languages: Node.js, Python, Java, Ruby, Go, Rust, PHP, C++, C#. Frameworks: React, Vue, Next.js, Astro, Rails, Django, Spring. Editors: VSCode, IntelliJ family, Vim, Emacs, Sublime Text. Operating systems: macOS, Windows, Linux. Pick any combination — the more you pick, the more rules end up in the file.
- Where do the templates come from?
- The rule sets are derived from the github/gitignore repository, which is published under CC0 (public domain). We trimmed them to what actually matters in 2026 — old AOL/CVS leftovers stripped, Yarn/PNPM/Vite caches kept, modern bundler outputs kept. The rules are bundled into the page; we don't fetch them at runtime, which is why the tool works offline.
- What does the file look like?
- A short header naming the templates you picked, then one ### Section ### per template containing that template's rules. Comments and blank lines from each template are preserved verbatim, so the file reads cleanly when you open it in your editor. The rules within each section keep their original order — we never reorder.
- How does deduplication work?
- If two templates both list the same rule (e.g. .env appears in Node, Python, PHP, and Ruby), the rule is emitted once — in the first template that listed it. Subsequent occurrences are dropped silently. Comments and blank lines pass through every section, so the section headers and explanations stay readable.
- Can I edit the generated file after?
- Yes — what you get is plain text. Open it in your editor, add project-specific paths, drop sections you don't need, comment things out. The generator is a starting point, not a contract. Most teams add a few of their own rules on top (build/, .vercel/, .turbo/, paths to local config) once they know the project's quirks.
- Why include OS-level rules like .DS_Store and Thumbs.db?
- Mixed teams (Mac + Windows + Linux contributors) end up committing each other's OS metadata files if those aren't ignored. The macOS template covers .DS_Store, ._*, .Spotlight-V100, Trashes. The Windows template covers Thumbs.db, Desktop.ini, $RECYCLE.BIN. The Linux template covers .Trash-*, .fuse_hidden*, swap files. Pick all three if your team uses all three.
- What about secrets like .env files?
- Every relevant template (Node, Python, PHP, Ruby, Go, plus Next.js and Astro) includes .env. If you've picked at least one of those, the rule is in your file. If you're paranoid (and you should be), double-check: open the generated file, search for .env, and confirm. Committing a .env file with API keys is one of the most common ways to leak credentials.
- How is this different from gitignore.io / toptal.com/developers/gitignore?
- Same idea, different execution. We run entirely client-side — no server, no API call, no rate limit. The trade-off: our template list is smaller (the most common 22-ish technologies, not the long tail of 500+). For a Node + Next.js + VSCode + macOS project, you'll get the same essential rules; for a niche stack (CodeIgniter, ColdFusion, MATLAB), use a different tool.
- Can I use the generated file in a private/commercial project?
- Yes. The rule sets are derived from github/gitignore, which is CC0 (public domain dedication) — no attribution required, no license to inherit, use them anywhere. A .gitignore is a list of file patterns; you can't really copyright a list of file patterns, but CC0 makes it explicit.
