webpage-review lets a client mark up a live web page. She installs a Chrome extension, opens the page and writes a comment on the part she means. Herman reads the threads in an admin panel. The tool is mounted under the public tools host.

​
The parts

Project

A piece of work under review. It holds a site whitelist, reviewer sessions and every thread.

Whitelist

The addresses that a reviewer may comment on. The server checks this, not only the extension.

Session

One reviewer token, with a role and an expiry date. Herman mints it in the admin panel.

Thread

One comment position on one page, with its replies and its open or resolved status.

​
How a reviewer works

1

Install the extension

Read the install page. The page is bilingual.
2

Paste the token

Herman sends one token. The token names the project and carries the expiry date.
3

Open a whitelisted page

The extension only works on the addresses in the project whitelist.
4

Write a comment

Select the part of the page. Write the comment. The extension anchors the comment to that position.
The reviewer chooses a display name one time. After that the name is fixed. The server reports canSetDisplayName so the extension offers the prompt exactly once.

​
Three rules the server enforces

The extension checks these too. The server checks them again, because a changed client must not be able to pass.
An unknown token gives 401. A revoked or expired token gives 410. The two answers are different on purpose: 410 tells the extension to stop and ask for a new token.
One origin can hold many unrelated projects. A single GitHub Pages account serves every repository of that user. A changed client that skipped its own check must still be stopped here, or one project’s token could write into another project.
The limit counts against the token, not the network address. One reviewer cannot spend another reviewer’s budget, and a shared office address cannot be used to throttle her.

​
Uploads

A reviewer can attach files to a comment. Three limits apply.
The API reports the effective file limit, which is the smaller of the project value and the server cap. Before 10 August 2026 it reported the project value alone. A project set to 200 MB confirmed 200 MB, and the server then refused at 64 MB. A limit is honest only when the number shown is the number enforced.

​
Paths are never shown to a reviewer

An /admin/api/* response can contain a filesystem path, such as boxPath. An /api/* response never contains one.
The reviewer is a person outside the project. The layout of the admin’s home directory is not hers to learn.