Open-source project
imfing/hextra avatar
imfing/hextra

Hextra: a Hugo theme that takes its accessibility checks seriously

🔯 Modern, batteries-included Hugo theme for creating beautiful doc, blog and static websites

2,364 stars427 forksHTMLMIT

At a glance

What is it?
The batteries-included Hugo theme for documentation sites, with offline FlexSearch, Tailwind CSS, multilingual support, and a Playwright suite that tests what a documentation reader actually does.
Who is it for?
Hextra is a good example of a theme whose engineering shows up in places visitors rarely notice. The visible list in the README is long but ordinary for a modern docs theme: dark mode, responsive layout, LaTeX, diagrams, shortcodes, multilingual, SEO tags and Open Graph.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 9 days ago.
What is it written in?
Mainly HTML, according to GitHub's language statistics.

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

Editorial analysis

What the theme claims, and what the tree backs up

Hextra is a Hugo theme for documentation, blogs and static sites, MIT licensed, with a demo at `imfing.github.io/hextra`. The README describes it as modern, responsive and batteries-included, and lists seven feature areas: a Tailwind CSS design inspired by Nextra, responsive layout with dark mode, a small footprint because Hugo ships as a single binary and no JavaScript or Node.js is required to use the theme, built-in offline full-text search powered by FlexSearch, bundled content extras including Markdown, syntax highlighting, LaTeX maths, diagrams and shortcodes, multilingual and SEO support with Open Graph and Twitter Card tags, and accessibility support through semantic markup, keyboard friendly behaviour and automated checks.

The repository layout supports most of that claim directly. `layouts/` holds the templates, `assets/` the stylesheets that Tailwind and PostCSS compile, `i18n/` the translations, `data/` the menu and configuration data, `static/` the files copied verbatim, `docs/` the theme's own documentation site, `examples/` a README for example usage, and `tests/` the browser test suite. There is a `playwright.config.ts`, a `postcss.config.mjs`, a `.prettierrc` and a `prettier-plugin-go-template` in the dev dependencies, which tells you the Go templates are kept formatted by the same tool as everything else.

Three readmes ship at the root: English, Simplified Chinese and Persian. The Persian file is a useful signal about who actually uses the theme, and the topic tags agree, listing `documentation`, `documentation-site`, `hugo-theme`, `static-site`, `tailwindcss`, `clean`, `golang` and `github-pages`.

Search that works without a service

The feature most likely to change your decision is offline full-text search with no extra configuration. Hugo static sites normally solve search with a hosted index such as Lunr or Algolia, which means either a build time dependency on a third party or a request on every keystroke. Hextra ships the index with the site and searches it in the browser using FlexSearch.

The work on this path is visible in the release history. Version 0.12.1, published 2026-03-06, added support for local or mirrored FlexSearch assets. That is the fix you want if your site is served from a domain with a strict Content Security Policy or if you host assets from a CDN, because a bundled index served from your own origin and one loaded from a mirror are different requests with different failure modes. The same release also fixed greedy text trimming, improved how relative images resolve inside page bundles that sit in i18n directories, and made the mobile sidebar include items declared in the menu under `main`. Version 0.12.2, from 2026-04-17, reduced noisy `console.warn` output in search breadcrumbs, which is the sort of small fix that only appears once enough people have used the feature in production.

The test suite reflects how much of this is treated as product surface rather than polish. `test:build` runs four spec files covering AsciiDoc rendering, KaTeX output, link rendering and search behaviour, split into `search-data.spec.ts` and `search-fragments.spec.ts`. Two separate search specs in a theme with no Node runtime at request time is a deliberate choice.

Accessibility as a test suite, not a claim

The `package.json` dev dependencies include `@axe-core/playwright` alongside `@playwright/test`, which is the concrete form of the accessibility bullet in the README. The scripts make the shape explicit: `test` runs the full Playwright suite, `test:a11y` runs only `tests/accessibility.spec.ts`, `test:mobile-menu` runs only `tests/mobile-menu.spec.ts`, and `test:build` runs the four render and search specs.

The split is the interesting part. The mobile menu checks were separated out of the a11y suite in v0.12.1, which means a failure in one no longer shows up as a failure in the other when you read CI output. That is a small organisational decision with a real effect on how fast a regression gets diagnosed, and it was made in the same release that fixed the mobile sidebar falling back to the content tree when the menu had no entries.

Two other accessibility shaped changes are worth noting. In v0.12.3 the inline table of contents click handler was removed so that a default Hextra install can avoid `unsafe-inline` under a Content Security Policy, which is both a security improvement and an indirect accessibility one, since strict CSPs tend to block legitimate progressive enhancement. The same release added an accessibility test for YouTube iframe internals, which is exactly the case where an embedded third party widget is the part of the page you do not control.

Running the theme's own site

Hextra builds its documentation site from the theme checkout itself, which is why the scripts carry unusual flags. `dev` runs `hugo server --source=docs --themesDir=../.. --disableFastRender -D --port 1313`, pointing the source at `docs/` and the themes directory two levels up so Hugo resolves the parent checkout as the theme. `dev:theme` goes further and adds a config file, an environment named `theme`, and the `-F` flag for fast render. `build` runs `hugo --gc --minify` with the same themes directory and source arrangement.

The stylesheet pipeline is a separate step rather than a Hugo asset build, which matches a Tailwind v4 setup: `build:css` shells out to PostCSS CLI with the `postcss.config.mjs` config and the production environment, compiling `assets/css/styles.css` into `assets/css/compiled/main.css`. Tailwind v4 appears in dev dependencies as both `tailwindcss` and `@tailwindcss/postcss`, both at `^4.3.0`.

There is also a `go.mod`, declaring `module github.com/imfing/hextra` and `go 1.21`. A Hugo theme does not need Go at runtime, so the file is tooling for editors and language servers that expect a module root. It also became a small compatibility story: v0.12.1 reverted an unintentional hard dependency on Go 1.26 back to Go 1.21, and v0.12.3 added compatibility helpers for deprecated multilingual Hugo APIs. If you are pinning a Go toolchain in CI, that revert is the release to read.

The shape of recent releases

Three releases are visible, all in the 0.12 line, and none of them is a feature release. Version 0.12.1 in March 2026 is the largest: local or mirrored FlexSearch assets, the greedy trim fix, page relative image resolution in i18n page bundles, mobile sidebar fixes for `menu.main` items and for a dropdown that auto-focused the search input, and the test suite split described above. Version 0.12.2 in April 2026 is smaller: the search breadcrumb console noise, a default copyright year update to 2026 across the `i18n/` files, dependency bumps for picomatch and yaml, and an added documentation entry for a site called Sortie.

Version 0.12.3, published 2026-05-05, is seven fixes: the CSP friendly table of contents change, the deprecated multilingual API helpers, a footer alignment fix, a fix to stop the demo cast being published in theme builds, the YouTube iframe accessibility test, the mobile menu fallback to the content tree, and page relative URL resolution in the details shortcode. Two of these only make sense to a maintainer rather than a user, which is a reasonable sign of what the remaining work is.

Read together, the pattern is a mature theme doing maintenance: correctness fixes, dependency bumps, deprecated API shims, and tests that keep growing. The documentation is the place the project puts its user facing communication, and each release points to the same v0.12 upgrade guide at `imfing.github.io/hextra/blog/v0.12/`.

Practical notes before you adopt it

The fastest path in is the starter template. The README's first recommendation is the Hextra Starter Template repository, using the Use this template button, which also ships a GitHub Actions workflow for deploying to GitHub Pages. That removes the awkward part of starting a theme from scratch, which is working out how the theme checkout relates to the content repository.

Second, the theme's documentation is not optional reading. Because Hextra configures a lot through Hugo's data files and shortcodes rather than through a single options block, the `docs/` site in the repository is the actual reference for what you can set. The README itself says as much and defers to it.

Third, note what the repository metadata says about scale: 2,364 stars, 427 forks and 104 open issues, pushed on 2026-09-27, not archived, MIT licensed, with the primary language recorded as HTML. A hundred open issues on a theme of this size is a normal level of background noise rather than a red flag, but the maintenance cadence above tells you what to expect: patches, not new direction.

Contributions go through `.github/CONTRIBUTING.md`, and the MIT licence means a fork for internal docs carries no obligation beyond keeping the notice. A root `CLAUDE.md` and `AGENTS.md` are also present, which suggests some contributor guidance is written for coding agents as well as people.

Editorial conclusion

Hextra is a good example of a theme whose engineering shows up in places visitors rarely notice. The visible list in the README is long but ordinary for a modern docs theme: dark mode, responsive layout, LaTeX, diagrams, shortcodes, multilingual, SEO tags and Open Graph. The parts worth reading the source for are the ones below that line. Search runs offline through FlexSearch with support for local or mirrored assets, added in v0.12.1. Accessibility is not a checklist item but a Playwright suite split into its own spec files, with an axe integration and a dedicated mobile menu test that was deliberately separated from the a11y suite so the two failures do not mask each other. v0.12.3 removed an inline table of contents click handler so a default install can avoid `unsafe-inline` under a strict Content Security Policy. If you are choosing a Hugo theme, that combination of offline search, a CSP friendly default and real browser tests is rarer than the feature list suggests, and it is the reason to pick this one over a prettier looking alternative.

Frequently asked questions

What is Hextra?

A Hugo theme for documentation sites, blogs and other static websites, MIT licensed, with a demo at imfing.github.io/hextra. The README describes it as modern, responsive and batteries-included, covering dark mode, offline full-text search through FlexSearch, syntax highlighting, LaTeX maths, diagrams, shortcodes, multilingual support and SEO tags. The starter template repository is the documented way to start a new site.

Does Hextra need Node.js or JavaScript at runtime?

Not to use the theme. The README states that Hugo is a static-site generator housed in a single binary and that no JavaScript or Node.js are needed to use Hextra, which is why it is described as fast and lightweight. Node and PostCSS appear only in theme development, where `build:css` compiles Tailwind styles before a Hugo build.

How does search work in Hextra?

It is offline full-text search powered by FlexSearch, with no extra configuration required according to the README. Version 0.12.1 added support for local or mirrored FlexSearch assets, which lets you serve the index from your own origin or a mirror. Two dedicated Playwright specs, `search-data.spec.ts` and `search-fragments.spec.ts`, run as part of `test:build`, and v0.12.2 cut noisy console warnings from search breadcrumbs.

What accessibility testing does Hextra do?

The README says interactive components use semantic markup, keyboard-friendly behaviour and automated accessibility checks. In practice the dev dependencies include `@axe-core/playwright` and `@playwright/test`, `test:a11y` runs `tests/accessibility.spec.ts`, and v0.12.1 separated the mobile menu checks into their own spec file so the two failure modes stay distinguishable. v0.12.3 also added an accessibility test for YouTube iframe internals.

What is the latest Hextra release?

The newest collected release is v0.12.3, published 2026-05-05. It is a bug fix release: it removed an inline table of contents click handler so a default install can avoid `unsafe-inline` under a strict Content Security Policy, added Hugo compatibility helpers for deprecated multilingual APIs, fixed footer alignment, stopped the demo cast being published in theme builds, added the YouTube iframe accessibility test, made the sidebar fall back to the content tree when the mobile menu has no entries, and resolved page relative URLs in the details shortcode.

Is Hextra still being maintained?

The repository is not archived and was pushed on 2026-09-27. The three most recent releases, all in the 0.12 line, are maintenance rather than feature work: correctness fixes, dependency bumps, deprecated Hugo API shims and a growing Playwright suite. The repository has 2,364 stars, 427 forks and 104 open issues. Expect steady patching and no new direction.

Official sources

  1. imfing/hextra on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
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/imfing-hextra.svg)](https://hysenlabs.com/projects/imfing-hextra)