GoogleChrome/samples: A Working Reference for New Chrome APIs

What GoogleChrome/samples actually is

This is a repository of samples tied to new functionality in Google Chrome, plus general samples. The README states that some samples correspond to an entry on chromestatus.com and that using that interface is currently the best way to browse. That sentence is the important one: the repository is not organized as a documentation site with a search index or a versioned API. It is a folder-per-feature collection, and the browsing experience lives elsewhere.

The audience is narrow. If you are writing a web page and want to know what a specific Chrome feature looks like in practice, a sample folder can show you the markup and the JavaScript. If you are the engineer who added a feature to Chrome, the README treats a sample as part of the feature's public surface, and asks contributors to mention that engineer in the pull request to solicit feedback. The repository is therefore both a reference for users and a review artifact for feature authors.

How the samples are structured and served

The top level is a flat list of feature folders: async-clipboard, compute-pressure, contact-picker, cookie-prefixes, css-custom-properties, dialog, and many more. Each folder holds the resources for one sample. There is no shared runtime and no package that consumers import.

The serving model is Jekyll. The README says that any files that start with a front matter block will be templated, and any other files will be served verbatim. So a sample author can either write plain HTML, JS and CSS, or opt into the templating system to avoid boilerplate. The README names image-rendering-pixelated and report-validity as canonical samples that use templates. The default branch is gh-pages, which matches the Jekyll with Pages workflow the README points to for local development. The data flow is therefore simple: a folder of files becomes a page, and if the file has front matter, the layout and includes under _layouts and _includes are applied before it is served.

Installing nothing, running the linter, and reading a first sample

There is no install step for the samples themselves. You browse them through chromestatus.com or read the folders directly. What you do install is the lint tooling, which the package.json defines.

The README says linting can be performed via npm run lint, and to make sure you run npm install first. The package.json confirms the script and the dev dependencies:

{
  "scripts": {
    "lint": "eslint ."
  },
  "devDependencies": {
    "eslint": "^8.46.0",
    "eslint-config-google": "^0.3.0"
  }
}

Running npm install and then npm run lint from the repository root lints the whole tree. The expected output is ESLint reporting on the sample files, with the Google style base configuration and the overrides in .eslintrc. The README notes that samples for a ChromeStatus feature are enforced this way, and that general samples are not held to the same enforcement in the same sentence.

To start a new sample, the README points at SAMPLE_STARTING_POINT as the starting point. The workflow it describes is: create the folder, add your HTML, JS and CSS, optionally use front matter for templating, then file a pull request against the gh-pages branch. For a general sample, the README says to just add all the resources in a dedicated folder, and cites mkbitmap as an example that is referenced and embedded in a web.dev article.

Where the repository is the wrong tool

The samples are tied to new functionality in each Chrome release. That is the point, and it is also the limitation. A sample written when a feature shipped may not reflect the feature as it behaves now, and the README does not describe any process for keeping an older sample in sync with a changed feature. There is no versioning scheme in package.json beyond 0.0.1, and no changelog in the repository.

The repository is also not a compatibility reference. Nothing in the README describes how a sample degrades in a browser that does not implement the feature, and the samples are selected for Chrome features specifically. If your question is which browsers support an API and what the fallback is, this repository answers a different question: what does the feature look like when it is present. Finally, because the samples are served through Jekyll and browsed through chromestatus.com, the repository alone does not give you a navigable index. A reader who clones it gets a directory of folders, not a searchable catalog.

How this differs from MDN and web.dev

MDN is the reference documentation for web platform APIs. It is organized by API, it carries compatibility tables, and it is written to describe behavior across browsers. GoogleChrome/samples is organized by Chrome feature and carries runnable files instead of prose. The difference in approach is the unit of content: MDN gives you a page about an interface, while this repository gives you a folder you can open.

web.dev is the closer alternative in tone, and the repository itself points at it. The README cites mkbitmap as a sample referenced and embedded in the article Compiling mkbitmap to WebAssembly on web.dev. That relationship is worth understanding: the repository can hold the interactive piece while the article holds the explanation. If you want the explanation, you go to web.dev or MDN. If you want the smallest working file set that exercises a Chrome feature, you go to the sample folder.

Maintenance, contribution cost and licence

The repository is not archived, and the last push was on 2026-09-18. The contribution path is a pull request against gh-pages, with the README asking contributors to mention the relevant Chrome engineer for feedback. That review step is a real cost: a sample is not merged on code quality alone, it is merged on whether it correctly describes the feature, and the reviewer is the person who built it. If you cannot find that person, the README suggests emailing them a link to the pull request.

The licence is Apache-2.0, stated in package.json and present as a LICENSE file at the top level. That is a permissive licence with an explicit patent grant, which matters if you copy sample code into your own project. Reusing a sample file means carrying its attribution and notice requirements. This is not legal advice; read the LICENSE file before copying anything into a product.

One dependency is worth noting because it is unusual for a samples repository: package.json lists built-in-ai-skills-md-agent-md under dependencies rather than devDependencies. The README does not explain it, and the folder list includes built-in-ai-rocks and downloading-built-in-models, so it appears tied to the built-in AI samples. A contributor adding an unrelated sample should not assume that dependency is part of the lint path.

Editorial conclusion

Adopt GoogleChrome/samples as a reference when you need to see a Chrome feature exercised in real HTML and JavaScript, and as a contribution target if you maintain a feature that lacks a demo. Do not treat it as a package to depend on: there is no published module to import, and the samples are organized by feature folder rather than by a stable API surface. Before relying on any single sample, check that the folder corresponds to the feature you care about, run the lint step locally, and confirm the sample's behavior against the current Chrome release, because the repository documents samples tied to new functionality and the feature may have changed since the sample was written.

Frequently asked questions

Official sources

1. GoogleChrome/samples on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README