# OnlineToolsBook: a Hugo-based Chinese manual for browser tools, and how to run it locally

> OnlineToolsBook is a Chinese-language catalogue of browser-based tools, published as a Hugo site whose home page is generated from the README. It is a reading project, not a library you install into an app.

**zhaoolee/OnlineToolsBook** — 🍭在线工具秘籍,为在线工具写一本优质说明书,让在线工具造福人类~ Online tool cheats, write a quality manual for online tools, make online tools benefit humanity~

- Repository: https://github.com/zhaoolee/OnlineToolsBook
- Website: https://zhaoolee.com/OnlineToolsBook/
- Stars: 2,673 · Forks: 248
- Language: CSS
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhaoolee-onlinetoolsbook

## What OnlineToolsBook actually is, and who the manual is written for

The README opens with a premise rather than a feature list: from a user's point of view, the ideal tool needs no installation and runs the moment you open a browser. OnlineToolsBook exists because those tools are hard to find and, once found, not always obvious to operate. The author describes the project as a quality open source Chinese manual for online tools.

The audience follows from that. It is written for Chinese-speaking readers who want a curated list rather than a search engine result page, and who are willing to read a short illustrated entry before clicking through. Each entry follows a numbered convention (T044, T043, T040 and so on), carries a title, and typically includes an animated GIF plus the tool's own web address. The README states that the author also collected resource sites alongside the tools, describing them as a second kind of find.

What it is not: there is no SDK, no CLI, no API. The repository is a website. The primary language recorded for the repository is CSS, which matches a Hugo theme and layout tree rather than an application runtime. If you arrived expecting a package to install into your own product, you are in the wrong repository, and the rest of this article is about running and reading the site instead.

## How the site is put together: Hugo, a README sync script, and a Pagefind index

The repository layout is a Hugo project: hugo.toml at the top level, with archetypes/, assets/, content/, layouts/ and static/ beside it. Tool entries live under content/, which is why the README links resolve to paths such as /tools/t044-squat/ and /tools/t043-compressjpg/ on the published site.

The interesting mechanism is in package.json. The build and dev scripts do not call Hugo directly. They first run a shell script, scripts/sync-home-from-readme.sh, and only then invoke Hugo:

```json
{
  "scripts": {
    "sync:home": "bash scripts/sync-home-from-readme.sh",
    "dev": "bash scripts/sync-home-from-readme.sh && hugo server --renderToMemory --noBuildLock --disableFastRender",
    "build": "bash scripts/sync-home-from-readme.sh && hugo --gc --minify",
    "index": "npx --yes pagefind --site public --output-subdir pagefind"
  }
}
```

That means the README is not just documentation. It is the source for the generated home page. Edit the README, run the sync, and the site's front page changes. It is a pragmatic choice for a single-author project, and it also means the README and the site cannot drift apart, because one is derived from the other.

Search is a separate step. The index script runs Pagefind over the built public/ directory and writes its output to a pagefind subdirectory. Pagefind is fetched through npx rather than pinned as a dependency, so the version you get is whatever npx resolves at that moment. For a site this size that is a minor concern, but it does mean the search index is not reproducible from package.json alone.

One more detail worth noticing: package.json declares "license": "ISC" while the repository's LICENSE file is Apache-2.0. The two disagree, and the repository-level licence is the one that matters for the project as a whole.

## Installing and running OnlineToolsBook locally

The README does not document a local build. What follows comes from package.json and the top-level layout, so treat it as the maintainer's own toolchain rather than a published install guide.

You need Node.js and a Hugo binary on your PATH. The scripts shell out to hugo and to bash, so this is a Unix-style workflow; on Windows you would need a bash-compatible environment. From the repository root, install nothing first and start the development server:

```bash
npm run dev
```

That command runs the README sync, then starts Hugo with --renderToMemory --noBuildLock --disableFastRender. The flags are worth reading: rendering to memory avoids writing generated files to disk, and disabling fast render forces a full rebuild on each change, which is slower but avoids stale partial output. Hugo prints the local address it is serving, conventionally on port 1313, and you should see the home page assembled from the README.

To produce the deployable site instead:

```bash
npm run build
npm run index
```

The build runs hugo --gc --minify and writes to public/. The index step then runs Pagefind against that directory. If you skip the second command, the site still works but the search interface has no index behind it.

To regenerate only the home page after editing the README:

```bash
npm run sync:home
```

A realistic first use is adding an entry. Create a new directory under content/tools/ following the existing naming pattern, add the entry there, then add a matching section to the README and run npm run dev to see both the home page and the tool page. If the home page does not change, the sync script is the first thing to check, not Hugo.

## Where OnlineToolsBook stops being useful

The project is a manual, and a manual inherits the weaknesses of the things it describes. Every entry points at a third-party website. The repository cannot keep those sites running, cannot warn you when one changes hands, and cannot tell you what a site does with the file you upload. Several entries involve uploading images or documents to someone else's server. The README presents browser-based operation as an advantage, and for convenience it is, but it also means your data leaves your machine, and the manual's description of a tool is not a security review of it.

There is also an editorial boundary problem. The README includes an entry titled around downloading from Baidu netdisk without a paid membership, and another around downloading YouTube videos. Whatever you think of those, they date quickly and they depend on the target service not blocking the technique. A reader who treats the manual as a stable reference will be disappointed.

Finally, the project publishes no releases. There is no versioned artifact to pin, no changelog to read, and no upgrade path other than tracking the master branch. The last push was on 2026-06-08, so the repository is not archived, but nothing in the repository indicates a release cadence or a compatibility promise. If your requirement is a dependency with a version number, this is the wrong project.

## OnlineToolsBook versus a general bookmark collection or a self-hosted tool suite

The obvious alternative is a personal bookmark folder or a link-sharing service. The difference is editorial work: a bookmark list records what you found, while OnlineToolsBook adds a written entry, an illustration, and a numbered index, and publishes all of it under an open licence so it can be forked and rebuilt. The cost is maintenance. A bookmark list cannot go stale in a way that embarrasses you; a published manual can, and this one carries entries from 2020 next to entries from 2024.

A different alternative is a self-hosted tool suite, where you run the utilities yourself instead of linking to someone else's site. That inverts the project's central premise, which the README states plainly: the ideal tool needs no installation. Self-hosting gives you control over your data and removes the dead-link problem, but it puts the operational burden back on you, which is exactly what this catalogue is trying to avoid. Neither approach is a superset of the other, and the choice depends on whether you value the absence of setup more than the absence of a third party.

There is also a structural difference worth noting. Because the home page is generated from the README by a script, the project can be forked and republished as your own curated list with a new README and the same Hugo machinery. That is a genuinely reusable piece of the repository, and it is arguably more durable than any individual tool entry.

## Licence, upgrade cost, and what the Apache-2.0 file covers

The repository ships an Apache-2.0 LICENSE file at the top level. That covers the repository's own content and code: the Hugo configuration, layouts, styles, the sync script, and the written entries. It does not cover the third-party websites the entries link to, and it does not cover the animated GIFs and screenshots if any of them were captured from elsewhere. If you intend to republish entries, the images are the part to check first, and the README does not state their provenance.

The package.json licence field says ISC, which conflicts with the LICENSE file. A tool that reads package metadata will report ISC; a human reading the repository will see Apache-2.0. For a site that is not published to a package registry this is cosmetic, but it is the kind of inconsistency that matters if you fork the project and redistribute it.

Upgrade cost is low in the mechanical sense and high in the editorial sense. Pulling new commits and rerunning npm run build is straightforward. What you cannot automate is re-checking whether the linked tools still exist and still behave as described. Pagefind is fetched through npx without a pinned version, so the search index is the one part of the build whose output can change without a commit to the repository.

## Conclusion

Adopt OnlineToolsBook if you want a Chinese-language, openly licensed reading list of browser tools and you are willing to check each linked site yourself, since the repository is a manual rather than a maintained service. Do not adopt it if you need an installable library, an uptime guarantee, or English documentation, because the README and content are in Chinese and the project publishes no releases. Before relying on it, verify three things: whether the tool page you care about still resolves at zhaoolee.com, whether the linked third-party site is still online, and whether the Apache-2.0 licence covers what you intend to reuse, since the licence applies to the repository content and not to the tools it points at.

## FAQ

### Is OnlineToolsBook legit?

The repository is public, carries an Apache-2.0 LICENSE file, and publishes its content at zhaoolee.com/OnlineToolsBook/. Legitimacy of the individual tools it links to is a separate question, because each entry points at a third-party site the project does not control.

### What does "online tool" mean in OnlineToolsBook?

The README defines it from the user's side: an ideal tool needs no installation and works as soon as you open a browser. The catalogue is built around that premise, so entries are web addresses rather than downloadable programs.

### What kinds of tools does OnlineToolsBook catalogue?

The README lists entries including a web squat counter, a batch image compressor, an image upscaler, a QR code generator, a short link generator, and a Markdown formatter for publishing platforms. It also states that the author collected resource websites alongside the tools.

## Sources

- [Issues](https://github.com/zhaoolee/OnlineToolsBook/issues)
- [License: Apache-2.0](https://github.com/zhaoolee/OnlineToolsBook/blob/master/LICENSE)
- [Project website](https://zhaoolee.com/OnlineToolsBook/)
- [README](https://github.com/zhaoolee/OnlineToolsBook/blob/master/README.md)
- [zhaoolee/OnlineToolsBook on GitHub](https://github.com/zhaoolee/OnlineToolsBook)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zhaoolee-onlinetoolsbook