Darkument inverts documents with a blend overlay, not a stylesheet rewrite

A blend overlay beats a stylesheet rewrite

Darkument solves a narrow, well understood problem: bright documents are hard to read at night, and the usual dark mode extensions break layouts, burn CPU or fail inside the built-in PDF viewer. The project targets students, researchers and professionals working late, and it is built for Chromium and Opera browsers. What makes the approach different is that it never parses or rewrites CSS. Instead the content script injects overlay elements as direct children of the page body and lets the GPU do the work through CSS blend modes. The transformation is stated as a single formula, Pixel_Final = | 255 - Pixel_Original |, which is why the project can describe itself as high fidelity inversion. Negation turns a white page black and a black page white, while midtones stay closer to their original values, so structure and legibility survive. Nothing about the page's own layout rules is rewritten, which removes the most common failure mode of dark mode extensions.

One Map in the service worker holds the toggle state

Darkument follows the Manifest V3 model with a decoupled background service worker and injected content scripts, and the two halves have clearly separated jobs. The service worker in background.js owns a volatile state tracker built on a Map, plus a script injection handler, and it reacts to two browser signals: the action button click and tab lifecycle events on update and removal. When you click the icon, the worker queries the map for the current tab's state. If the tab is already inverted, the worker executes a script that fades out and removes the overlay element with the id darkument-overlay, sets the tab state to false, and resets the badge to empty. If it is not inverted, the worker injects a script that creates the overlay and applies the blend mode, sets the state to true, and sets the badge to ON with an active icon. The per tab granularity is the point, since inverting one document leaves every other open tab alone.

PDFs work because the viewer lives in the DOM

The PDF case is where most similar extensions give up, so it is worth being precise about why Darkument can handle it. Browsers render PDFs with internal HTML5 parsers such as PDF.js, and the README's point is that these documents are exposed inside the standard web frame DOM rather than in a separate native surface. Because the document is reachable as a normal DOM, the service worker can inject negation overlays into local document frames once the user has allowed local file access. That permission is the friction point, and the project handles it with a dedicated onboarding flow rather than leaving users to guess: src/pages/ holds thankyou.html as a local file permissions guide and thankyou.js as a dynamic permission listener. The extension supports both local file:// documents and remote document URLs, and the badge plus icon state is the only feedback channel, which keeps the interface out of the page itself.

Install from a store, or load the src directory unpacked

Three installation paths are documented, and the manual one is the most useful for anyone reading the code. The published builds are on the Chrome Web Store and on Microsoft Edge Addons, and the README marks the Chrome route as recommended. For a local checkout, the steps are short: download the latest source package from the releases page, open chrome://extensions or edge://extensions, toggle Developer Mode on in the upper-right corner, then click Load Unpacked and select the /src directory of the project. Selecting the src folder rather than the repository root matters, because the manifest lives inside src/ alongside background.js, the icons directory and the onboarding pages. The store listings are described in store_listing.md, and the repository also keeps store_assets/ for the listing images and assets/ for the brand banner used in the README.

The build script is a PowerShell one-liner

The project builds a release archive with npm, but the work is done by shelling into PowerShell, and that is the single biggest practical constraint on the codebase. The README lists npm run build as compiling the files from src/ into a release .zip archive inside build/, with PowerShell named as the platform, and npm run clean as deleting any compiled .zip archives. The package configuration is small and points the entry point at the service worker:

{
  "name": "darkument",
  "version": "1.0.4",
  "description": "Invert PDFs, Documents and Web-Pages for late-night study sessions.",
  "main": "src/background.js",

The author and licence fields and the repository URL follow the same file:

  "author": "Ahmad Hassan",
  "license": "MIT",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/Ahmad-Hassan-0/Darkument.git"
  }

The build directory holds production release ZIP artifacts, and scripts/ contains the automation, so the pipeline is a small local script rather than a bundler or a CI dependency. The declared prerequisites are Node.js and Windows PowerShell or a compatible shell, which is a fair assumption on the developer's machine and a portability problem for everyone else.

No test script, no releases, and a state map that does not persist

Three limitations are visible in the project itself. The package.json test script is a placeholder that prints an error and exits, so there is no automated test suite behind the build. The repository publishes no GitHub releases, which sits awkwardly against the README's manual installation step that points at a releases page for the source package, and against a version field of 1.0.4 that no tagged release corresponds to. Third, the state tracker is described as volatile and lives in the background service worker, so the per tab preference is remembered for the life of that worker rather than stored on disk, and the README does not say whether a browser restart restores it. The repository is not archived and the last push was on 2026-07-22, so the extension is still being worked on, and PRIVACY.md plus the local only design claim are what back the zero footprint statement.

Editorial conclusion

Darkument fits a student or researcher who reads academic PDFs late at night and wants dark mode that survives the browser's own PDF viewer, and the difference blend approach means it will not fight a site's layout the way a stylesheet rewrite would. It does not fit a workflow that needs a scripted build on Linux or macOS, because npm run build shells out to powershell, and it does not fit a team that wants test coverage, since the package.json test script is a stub that exits with an error. Before installing it, grant local file access for file:// documents, and check the version in package.json against the copy in your browser, since the repository publishes no GitHub releases and the last push was on 2026-07-22.

Frequently asked questions

Official sources

1. AhmadHassan-BTed/Darkument on GitHub
2. Issues
3. License: MIT
4. Project website
5. README