Open-source project
flutter/website avatar
flutter/website

flutter/website: The Source Repository for docs.flutter.dev and flutter.dev

Flutter documentation web site

3,121 stars3,505 forksDartNOASSERTION

At a glance

What is it?
flutter/website is the Git repository that contains the documentation and marketing website content for the Flutter framework, built with Jaspr and hosted on Firebase. It is the right starting point for developers who want to contribute corrections, add code examples, or understand how Flutter's public documentation is structured and built.
Who is it for?
flutter/website is the correct repository for contributors who want to fix documentation errors, add code examples, update navigation, or improve content on docs.flutter.dev or flutter.dev. API documentation for individual Flutter classes lives in the `flutter/flutter` repository in the source code, not here.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Dart, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What flutter/website Is and What It Covers

docs.flutter.dev is Flutter's primary documentation site: installation guides, cookbook examples, performance advice, platform integration references, and release notes. flutter.dev is the marketing site and blog. Both are generated from this repository.

The repository is built with Jaspr, a Dart-based web framework for static site generation. The generated site is hosted on Firebase. Contributors write or edit content in this repository; the Flutter team deploys from it.

The separation between this repository and `flutter/flutter` is important: the API reference documentation at `api.flutter.dev` is embedded in Flutter's source code as doc comments. Changes to API docs go to `flutter/flutter`, not here. The README states: "If you have an issue with the API docs on api.flutter.dev, please file them on the flutter/flutter repo, not on this repo."

The repository also contains runnable code examples under `examples/`, which are checked against the site content as part of the validation pipeline. These cover animation, accessibility, layout, state management, testing, internationalization, and many other Flutter topics.

Repository Structure and Key Directories

The top-level structure includes: `examples/` (runnable Dart/Flutter code samples referenced in the docs), `packages/` (Dart packages used by the build tooling), `sites/` (content for the two sites), `tool/` (the `dash_site` build tool), and configuration files including `pubspec.yaml`, `analysis_options.yaml`, and `.github/` for CI workflows.

The `examples/` directory is organized by topic: `examples/animation/`, `examples/cookbook/`, `examples/state_mgmt/`, `examples/testing/`, `examples/layout/`, and many others. These are real Flutter projects; they have their own `pubspec.yaml` and `analysis_options.yaml`. The build tool validates that code in the documentation matches what is in these example projects.

Contributions that add or remove pages, change navigation structure, or modify code samples need a local build to verify. Small text changes (typo fixes, wording improvements) can often be made directly through the GitHub UI without a local build.

The README notes that the `sites/` directory distinguishes the documentation site (`docs.flutter.dev`) from the marketing site (`flutter.dev`). The `dart run dash_site --site=www` flag targets the marketing site and blog; the default targets the documentation site.

Setting Up a Local Build to Serve the Documentation

The build requires Flutter (which includes Dart). Verify the installation:

console
flutter --version

Clone the repository:

bash
git clone https://github.com/flutter/website.git

Fetch Dart dependencies from the repository root:

console
dart pub get

Validate the setup and see available commands:

terminal
dart run dash_site --help

Serve the documentation site locally:

terminal
dart run dash_site serve

Serve the marketing site and blog:

terminal
dart run dash_site --site=www serve

Both commands print the local port to the terminal. The site rebuilds automatically on most content changes. For changes that do not trigger a rebuild, exit and rerun the command.

To validate code examples and check for broken links before submitting a pull request, run:

terminal
dart run dash_site check-all

This command checks that example code is up to date and matches site standards, and verifies internal links and Markdown link references. The README instructs contributors to address any errors or warnings before submitting.

Contribution Guidelines and Style

The README documents the contribution process and style requirements. Flutter's documentation follows the Google Developer Documentation Style Guidelines. Specific points called out include: avoid "i.e." and "e.g.", avoid first person, and avoid the future tense. The style guide highlights and word list are linked from the README.

The README asks that contributors not run content through grammar-checking tools like Grammarly and submit those changes as pull requests. This is a practical concern: automated grammar tools tend to make stylistically uniform changes that may conflict with the project's deliberate tone.

Issues labeled "PRs welcome" signal that the team expects external contributions on that specific issue, but the README notes that pull requests on other issues are also welcome.

For changes involving code samples, new pages, or navigation, the contributor should build and test locally. The `check-all` command verifies examples; broken link detection requires a full local build first.

Code samples added to the documentation must have a corresponding runnable example under the appropriate `examples/` subdirectory. The build tooling cross-references examples with the documentation content.

What This Repository Does Not Cover

flutter/website does not contain the Flutter framework source code (that is `flutter/flutter`), the Flutter engine (that is `flutter/engine`), or the Dart language specification. Changes to how Flutter itself works, new widgets, or bug fixes to Flutter's behavior are out of scope here.

API documentation (the reference for `StatefulWidget`, `Navigator`, `Theme`, and every other class in the Flutter SDK) lives as doc comments in `flutter/flutter`. Filing issues against incorrect API docs in this repository will be redirected to `flutter/flutter`.

The `flutter/flutter` repository has its own issues and pull request workflow. The two repositories have separate issue trackers; the README for flutter/website links to `flutter/flutter/issues` for API doc issues.

Contributors interested in contributing to the Flutter framework itself (new features, bug fixes, performance work) should read the contributing guide in `flutter/flutter`, not this repository. The two workflows are separate.

Build Tooling: dash_site and Jaspr

The `tool/` directory contains the `dash_site` build tool, a Dart command-line application. It wraps Jaspr's site generation pipeline and adds Flutter-specific validation: checking that code samples compile, verifying that Markdown link references resolve, and running linter checks against code in the `examples/` directory.

Jaspr is a Dart web framework for building static and server-rendered websites. It replaces an earlier Jekyll-based setup (older versions of flutter/website used Jekyll). Jaspr allows Flutter documentation contributors to write tooling in Dart, the same language as Flutter itself.

The repository root includes a `pubspec.yaml` that declares dependencies for the `dash_site` tool. Running `dart pub get` at the root installs these. The example projects under `examples/` each have their own `pubspec.yaml` and are separate packages.

Fire base Hosting is used for deployment. Cloud Build configuration lives in `cloud_build/`. The `.github/` directory contains the CI workflow (a GitHub Actions build that runs `check-all` on pull requests).

Maintenance and License

The last push to this repository was on 2026-09-25. Continuous integration runs on every pull request. The repository is actively maintained by the Flutter Developer Relations team.

The license for this repository is marked as NOASSERTION in the repository metadata, meaning the `LICENSE` file was not a recognized SPDX identifier at fetch time. An `AUTHORS` file and a `CODEOWNERS` file are both present at the top level. The `CODEOWNERS` file defines which Flutter team members review pull requests for different parts of the repository.

The Flutter contributors Discord (`#hackers-devrel` channel) is linked from the README as the place to ask questions about documentation contributions.

Editorial conclusion

flutter/website is the correct repository for contributors who want to fix documentation errors, add code examples, update navigation, or improve content on docs.flutter.dev or flutter.dev. API documentation for individual Flutter classes lives in the `flutter/flutter` repository in the source code, not here. Contributors should run `dart run dash_site check-all` before submitting a pull request to catch broken links and code sample issues. The last push to this repository was on 2026-09-25.

Frequently asked questions

How do I serve the flutter/website documentation locally?

Clone the repository, run `dart pub get` from the root, then run `dart run dash_site serve`. This starts a local server for docs.flutter.dev. Use `dart run dash_site --site=www serve` for the flutter.dev marketing site instead.

Where should I file issues about Flutter API documentation?

API documentation for Flutter classes (at api.flutter.dev) is embedded in Flutter's source code. File those issues on the `flutter/flutter` repository, not on `flutter/website`. The README explicitly directs API doc issues to `flutter/flutter`.

What validation should I run before submitting a PR to flutter/website?

Run `dart run dash_site check-all` from the repository root. This verifies that code in the `examples/`, `sites/`, and `tool/` directories is up to date and meets site standards. Address any reported errors or warnings before submitting.

Official sources

  1. flutter/website on GitHub
  2. Issues
  3. Project website
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/flutter-website.svg)](https://hysenlabs.com/projects/flutter-website)