cppwp: a browsable HTML edition of the C++ working draft

The standard, rendered as a website

The repository description is short: an HTML version of the current C++ working paper. The readme's first line of substance is the qualifier that matters most, that this is completely unofficial, of course.

That word is not a formality. The C++ standard does not exist as a single finished artefact; it exists as a sequence of working drafts that the committee revises at each meeting, and the text you read changes between drafts. A rendering of the current working draft is therefore a convenience for reading, not an authority.

The mechanism is a tool, and the readme credits it directly. The pages are generated using cxxdraft-htmlgen, from the Eelis project, which takes the committee's LaTeX sources and produces linked HTML. That is the crux of the project: the LaTeX sources are the upstream input, and the HTML is a derived artefact, so the HTML cannot be newer or more accurate than the draft it was built from.

The repository layout confirms that structure. There is a draft/ directory for the upstream sources, a gh-pages directory for the published output, several submodules for the generator itself (cxxdraft-htmlgen, cxxdraft-htmlgen-networking and cxxdraft-htmlgen-ranges), a set of gen_html_*.sh scripts for the various documents, a collection of .patch files including htmlgen.patch and one per draft revision, and a lastbuild.sig file that records the last build.

The patches are the most interesting part of the layout. Keeping a patched copy of the generator, one patch file per revision, is how the project tracks what it had to change to keep producing output from a moving upstream, and the per-draft patch files mean the history of those changes is preserved rather than squashed into one diff.

The primary language of the repository is listed as Shell, which fits: the substantive code here is the generation scripting, not the rendering itself.

Eight drafts and two technical specifications

The published index is the readme's central content, and it is worth reading as a history of the standard's shape as much as a list of links.

* Tip of trunk: [HTML](https://timsong-cpp.github.io/cppwp/) [Full PDF](https://timsong-cpp.github.io/cppwp/draft.pdf)
* N3337 (C++11 + editorial fixes): [HTML](https://timsong-cpp.github.io/cppwp/n3337/) [Full PDF](https://timsong-cpp.github.io/cppwp/n3337/draft.pdf)
* N4140 (C++14 + editorial fixes): [HTML](https://timsong-cpp.github.io/cppwp/n4140/) [Full PDF](https://timsong-cpp.github.io/cppwp/n4140/draft.pdf)

Each entry is a document number, a one line description, and a pair of links, one to the HTML rendering and one to a full PDF. The document numbers are the committee's own working paper numbers, and the descriptions tell you what each one is: N3337 is C++11 with editorial fixes, N4140 is C++14 with editorial fixes, N4659 is the March 2017 post-Kona working draft for the C++17 committee draft, N4861 is the March 2020 post-Prague working draft for C++20, N4868 is the October 2020 pre-virtual-plenary working draft for C++20 plus editorial changes, N4950 is the C++23 committee draft with editorial changes, and N5050 is the C++26 committee draft.

So the archive spans three standard versions and eight revisions of them, and the tip of trunk is always available alongside the frozen ones.

On top of the working drafts there are two technical specifications published separately.

* Ranges: [HTML](https://timsong-cpp.github.io/cppwp/ranges-ts/) [Full PDF](https://timsong-cpp.github.io/cppwp/ranges-ts.pdf)
* Networking: [HTML](https://timsong-cpp.github.io/cppwp/networking-ts/) [Full PDF](https://timsong-cpp.github.io/cppwp/networking-ts.pdf)

Ranges and Networking are the two technical specifications that the standard refers to by number rather than incorporating by value, and giving each of them its own HTML rendering is arguably more useful than the drafts themselves for a developer trying to find out what the ranges library actually promises. The separate generator submodules cxxdraft-htmlgen-ranges and cxxdraft-htmlgen-networking, with their own patch files, exist for the same reason.

Every entry offering both HTML and a full PDF is a good decision for this audience. The HTML is for reading and linking; the PDF is for printing, for offline reference, and for anyone who wants the same document the committee circulated.

Why a rendered standard beats a PDF for reading and linking

The argument for this project is not that the C++ standard should be read differently. It is that the same text, in the same form, becomes more usable.

A working draft PDF is a linear artefact. The C++ standard at the size of the current drafts is thousands of pages, and finding a specific paragraph in it means either searching the PDF or using the document's own index and hope the numbering survives the search. In HTML, the paragraphs are anchorable, which means a discussion, a bug report or a lecture slide can point at an exact clause and the reader lands on it.

That is the single most valuable property here, and it is the reason the tip of trunk is published alongside every numbered draft. The committee's own documents change constantly, and a link into a live rendering of the current draft stays meaningful in a way that a link to a PDF of a specific meeting cannot.

The generator is doing real work to make that possible. The upstream source is LaTeX with the committee's own macros, and those macros are not standard LaTeX; they carry the semantics of the standard's own cross-references, its example blocks, its tables and its notes. Turning that into linked HTML with stable anchors requires understanding how the draft is structured, which is why the project maintains a patched copy of the generator rather than using it unmodified. The htmlgen.patch file is the accumulated set of those changes.

There is a second, quieter benefit. A rendered document with per-paragraph identifiers can be diffed between drafts in a way that a PDF cannot, and the presence of one patch file per draft revision suggests the project does exactly that, since each patch is named after the document it was needed for.

The practical limitations of the approach follow from the source. The HTML is only as good as the LaTeX the committee publishes, so anything the generator cannot interpret does not appear. And because the pages are generated, a reader cannot easily tell from a paragraph whether it is final wording, a proposed change or a note from a paper, since the rendering flattens some of that distinction.

Running the generation yourself

The repository does not document an install or a run procedure in the readme, and there is nothing in the visible documentation that gives you the commands. What the layout does tell you is how the generation is organised.

There is a shell script per document. gen_html.sh handles the standard draft itself, gen_html_ranges.sh handles the Ranges technical specification, and gen_html_networking.sh handles the Networking one. The gen_html_std.sh name completes the set, so the four scripts cover the main draft and the three additional documents.

Each script is presumably a thin wrapper, because the actual generation lives in the submodules. cxxdraft-htmlgen is the upstream generator as Eelis wrote it, and cxxdraft-htmlgen-ranges and cxxdraft-htmlgen-networking are the variants for the two technical specifications. The .gitmodules file is what pulls them in.

The patch files are the manual intervention. There is htmlgen.patch for the main generator, ranges_htmlgen.patch and networking_htmlgen.patch for the two variants, and then one patch per draft revision: n4659.patch, n4861.patch, n4868.patch, n4950.patch and n5050.patch. The naming pattern is consistent with a project that regenerates each draft in turn and keeps the change needed for that revision separately, so a rebuild of an old draft still works.

The draft/ and gh-pages/ directories complete the picture. draft/ holds the committee's LaTeX sources, and gh-pages/ holds the published HTML that GitHub serves. The lastbuild.sig file at the root records the last build, which is a reasonable thing to keep for a mirror whose output has to be reproducible.

Because the readme does not give the commands, anyone who wants to rebuild rather than just read should start with the scripts themselves and with the upstream cxxdraft-htmlgen documentation. There is no supported entry point described in the visible documentation, and that is a genuine gap for anyone who wants to run the pipeline rather than consume the output.

Where cppwp is the wrong tool

There are three clear cases where this is the wrong place to look, and one where it is exactly right.

The first is anything where the standard's wording is legally or technically load bearing. A committee working draft is a proposal. It changes at the next meeting, its wording is not final, and the readme's own warning that this is completely unofficial is the correct summary. If a contract, a specification or a test suite depends on the exact text of a clause, that text has to come from the published standard or from the working draft of the meeting where it was agreed, and it has to be pinned to that document number, not read off the tip of trunk.

The second is any question about what your compiler actually implements. The standard says what the language is; the compiler is what you have. The working draft tells you what the committee is proposing, and a compiler shipped today implements some earlier or different text entirely.

The third is a project that needs the standard offline in a searchable form. This is HTML on the web. There is no packaged corpus here, no search index, and no offline copy beyond the per-draft PDFs.

The case where it is exactly right is a person who needs to read the standard and point at it. A teacher linking to a paragraph in a lecture, a compiler implementer checking the wording of a rule they are implementing, a reviewer asking what the committee currently says about a feature, a standards discussion where the exact wording of a proposal matters. In all of those, a link into the HTML is better than a PDF, and having the numbered drafts archived means an argument about what the standard said in 2017 can be checked.

On the maintenance and licence position, the facts are thin and worth stating. The last push was on 2026-08-18, which is a little over two months before the current date, so the mirror is being kept in step with the committee's output rather than abandoned. The repository has no GitHub releases, and the licence field is listed as unknown, with a LICENSE file at the root. For a mirror of a document the committee publishes under its own terms, the licence question is mostly about the tooling rather than the text, but read the LICENSE file before you redistribute anything derived from it. The upstream LaTeX sources carry their own terms, and those are the ones that matter for the text itself.

Editorial conclusion

cppwp suits a C++ developer or teacher who wants to link to a specific paragraph of the standard or read it with working navigation, and it does not suit a project that needs an authoritative copy of the standard, because the readme states plainly that this is completely unofficial and the published text reflects working drafts that change with every meeting. Before you rely on it, check the version you are reading against the standard your compiler implements, and note the licence field on the repository is listed as unknown.

Frequently asked questions

Official sources

1. Issues
2. README
3. timsong-cpp/cppwp on GitHub