snippets-web is where the Firebase docs keep their runnable code

The docs page is a view, the repository is the source

The repository describes itself plainly as holding code snippets used in web documentation on firebase.google.com, and the important sentence is the second one. These snippets are part of the documentation and are best read in the context of a documentation page rather than used directly, and the README points anyone who wants to get started with the Firebase Web SDK to the quickstart-js repository instead. That framing sets the expectations correctly. This is not an SDK, not a template and not a package you install. It is the source of the code that a reader sees on a documentation page. The example given makes the mechanism concrete. On the page about lists of data in the Realtime Database, each snippet on the page is dynamically included from the source in this repository, in that case mostly from the file database/lists-of-data.js. So the page is assembled at build time from files here, and a change to a file here becomes a change to the published documentation.

Region tags are the contract between the file and the page

The mechanism that makes that work is a pair of comment markers. Each snippet has a region tag, which the README defines as the // [START tag] and // [END tag] comments, and the code between the tags can be included in the documentation.

// [START tag]
// [END tag]

The reason for the arrangement is stated directly: keeping the code on GitHub rather than hard-coded into the HTML of the documentation allows the team to ensure the code is correct and up to date. That is the whole point of the design, and it is a good one. A documentation page with inline code blocks has no way to be tested or to be the same as what the reader copies, whereas a snippet that lives in a repository can go through pull request review, be linted, and be exercised by a test job. The tag markers also let one file hold several snippets for the same page, so the page pulls the pieces it needs from a shared source file rather than duplicating setup code across a dozen examples.

Every product gets a folder, and the next generation gets its own

The top level directory listing is a map of the documentation surface. There are folders for analytics, appcheck, auth, database, firebaseapp, firestore, functions, installations, messaging, remoteconfig, storage, perf and placeholder, and the vast majority of them come in two flavours. Each product has a directory with a plain name and a sibling with the same name and a -next suffix, so appcheck and appcheck-next, auth and auth-next, database and database-next, firestore and firestore-next, functions and functions-next, messaging and messaging-next, remoteconfig and remoteconfig-next, storage and storage-next, analytics-next and perf-next among them. Two things are missing from that pairing, analytics and perf, which appear only in the -next form in the listing. What the suffix denotes is not explained in the README, but the pattern of one directory per documented product and one per upcoming product suggests the newer modular or namespaced API surface against the older one.

A pnpm workspace with a separation step and a lint that skips its own output

The package.json is small and describes a documentation build rather than an application. The package manager is pnpm at version 12.10.1, the package is an ES module, and the scripts are the interesting part. The snippets script removes the snippets directory with rimraf and then runs node scripts/separate-snippets.ts, which is the step that takes the tagged regions out of the source files and writes them into a separate tree. The lint script lists tracked files, filters out anything under snippets/ and anything that is not a .js file, and pipes what is left through eslint, and the format script is the same command with --fix appended. So the linted set is the source files, and the separated snippets directory is generated output that is deliberately excluded from linting, which makes sense since it is derived, and also means a broken snippet is caught by the pipeline rather than by the linter. The compile script runs compile across every workspace package with a concurrency of four, and the bootstrap script is just pnpm install.

The readme is honest that these files are not for direct use

It is worth pausing on the sentence that says these snippets are best read in the context of a documentation page rather than used directly, because it rules out a whole category of misreading. Someone who finds database/lists-of-data.js on GitHub might reasonably assume it is a maintained library of database helpers, and it is not. It is a demonstration, and the parts of it that are shared between examples are shared because two pages need them, not because the API is stable. The licence is Apache-2.0, which is permissive enough to copy from, and the repository carries a SNIPPETS.md file at the root and a scripts/ directory, and a tsconfig.json.template alongside a tsconfig.json, suggesting that the snippet files are authored in JavaScript and the tooling around them is TypeScript. The project also has a CI badge for the GitHub Actions workflow, so something is checked on every change.

What the repository does not give you

The limits are structural and easy to state. There is no package to install, no exported API, and no versioned contract, so there is nothing to depend on and nothing that can break your build. The examples are also not a tutorial, and the README is direct that the quickstart-js repository is the right starting point for anyone who wants to learn the SDK, which means the order of use matters: learn from the quickstart, then read the snippets to see how a specific documented task is put together. The second limit is that documentation snippets tend to be minimal, since a page that reads well and a page that shows a complete error handling path are different documents, and a reader who copies a snippet into their own code may find that the surrounding application is doing work the page does not show. The third is the workflow. Contributions are welcome and the README points at CONTRIBUTING.md for the guidelines, but the loop from a change in a file here to a change on firebase.google.com involves the documentation build, and the sample in the README shows the page rather than the pipeline.

Editorial conclusion

snippets-web suits a Firebase developer who wants to read the exact code the documentation renders, or who wants to propose a fix to a documented example and see it applied to the live page. It is the wrong tool for learning the Firebase Web SDK from scratch, because the README says so directly and points to the quickstart-js repository instead, and it is the wrong tool for anything you intend to depend on, because the repository is documentation infrastructure rather than a library with a public API. Before contributing, read CONTRIBUTING.md, and note that the lint script deliberately excludes the generated snippets directory, so the code you edit and the code that is checked are not the same set. The last push was on 2026-10-09 and the repository publishes no releases.

Frequently asked questions

Official sources

1. firebase/snippets-web on GitHub
2. Issues
3. License: Apache-2.0
4. README