Manifest: a grid-based pinboard for notes that never leaves the browser

Click and drag anywhere to create a note, then it snaps to the grid

Manifest is a grid-based pinboard for note taking, and the interaction model is the whole idea. You click and drag anywhere on the canvas to create a note, and the note snaps to a grid determined by the current window size. Notes can be moved, resized and deleted.

The grid is derived from the viewport rather than being a fixed cell size, so a note's position is relative to the window you created it in. The README credits bnjm with the help on the grid snapping logic, and the acknowledgements also thank everyone who helped test the first release.

What this buys is speed. There is no document model, no folder tree, no title bar, and no modal dialog. A note appears where you dragged it, at a size you dragged it to. The cost is that a board is a spatial arrangement rather than a list, which is a deliberate trade rather than a limitation the project claims to have solved.

The project describes itself as completely open source and free, and it asks for a small donation through a Stripe link to support development, with LiberaPay also offered to help pay for domain and server costs even though the application itself makes no network calls.

No server, no analytics, no account, and local storage does the work

The FAQ answers the analytics question with a single word: zero. Manifest provides no connection to a server, and no data is ever sent outside of the browser. All data is stored locally.

The README says the browser's local storage is used to save notes between sessions and while offline. That is the entire persistence layer, and it is worth thinking about what that implies rather than treating it as a feature description. Local storage is a key-value store scoped to the origin, so notes live in the browser profile of the machine that created them. Clearing site data removes them. There is no export path described anywhere in the README, no backup mechanism, and no account to recover from.

This is a coherent design for a tool whose stated promise is that nothing leaves the browser, and it is also a narrow one. The offline claim and the privacy claim are the same claim: the application works with no network because the data never needed a network.

The application is a progressive web app, so most popular browsers can install it as a standalone application. The FAQ is direct about why there is no desktop build: the easiest route would be Electron or DeskGap, which are web views themselves, so a desktop-specific app would offer nothing unique. That reasoning is sound, and it also means the installed application is only as good as the browser's PWA support.

Vanilla JS and SASS bundled with Parcel, with no runtime framework

The FAQ gives the stack in one line: vanilla JS and SASS, bundled with Parcel. The manifest confirms it, and the dependency list backs it up in detail.

The build tooling is Parcel, with the SASS transformer, the webmanifest transformer, the XML packager, the raw URL packager, a Babel environment preset, a minify Babel preset, and a service worker package. Babel itself is present with the `babel-plugin-jsx-pragmatic` plugin, and ESLint with the standard config, the import and node plugins, and the promise plugin. There is no React, Vue or Svelte in the dependency list, and no state management, router or CSS framework.

The scripts show the shape of the workflow. The dev server runs Parcel against `src/index.html` on port 3000 with caching disabled, the build runs `parcel build` with content hashing and the cache turned off and the public URL set to `./`, and there is a prebuild step that removes the `dist` directory first. A pre-commit hook runs the lint task.

The three scripts are defined in the package manifest as:

    "lint": "./node_modules/.bin/eslint . --fix",
    "dev": "parcel ./src/index.html --port 3000 --no-cache",
    "prebuild": "rm -rf ./dist/",
    "build": "parcel build ./src/index.html --no-content-hash --no-cache --public-url ./"

The `dev` script is the one a contributor wants, since it serves the app with the cache off so a reload always shows the current source. The `build` script produces the `dist` output that a static host serves, and the public URL of `./` is what makes the built app work from a subdirectory on a static host.

Two details in the manifest are worth flagging for anyone rebuilding it. The `browserslist` field is a long explicit list of the last two versions of a dozen browsers, which is a 2020-era approach to target selection. And the toolchain versions are pinned to their era as well, with Parcel at `^2.12.0`, Babel 7 and ESLint 6, none of which have moved in six years. Nothing here is broken, but the build is running on frozen dependencies.

The feature set stops where the ecosystem choices were avoided

The FAQ reads as a list of decisions rather than a list of features, and the reasoning is consistent throughout.

There is no browser extension, and the reason given is that the author did not want to invest too much in a single ecosystem. There is no desktop app, for the web-view reason described above. Mobile is ruled out outright: Manifest is not a mobile-centric product, and this is intentional, because the specific experience and interactions it offers rely on more accurate types of input. If mobile support were made possible it would most likely require its own bespoke experience. Tablet support is described as a definite goal.

Dark mode is supported and follows the OS preference by default. You can toggle between light and dark with the alt and t keys together, and the preference is saved.

What is absent is as telling as what is present. There is no sync, no collaboration, no export, no search across notes, and no attachments. The FAQ does not mention any of these, which means a reader is left to infer that a board is a local, single-user, text-only artifact.

The dark mode implementation is worth noting for a small detail. Because the preference is saved and the default comes from the OS, the state lives in the same local store as the notes. That is tidy, and it also means the same clearing of site data takes your theme preference with it.

The release history stops in 2020 while the source moved in 2026

The maintenance picture needs stating plainly, because the numbers disagree with each other.

The listed GitHub releases are v1.1.0 from 2020-01-17, v1.0.1 from 2020-01-09, and v1.0 from 2020-01-09. Three releases in nine days at the start of 2020, and then nothing tagged since. The `package.json` in the repository reads version 1.1.1, so there is a version that was never tagged as a release, or the manifest was bumped without a corresponding GitHub release.

The last push was on 2026-04-02, and the repository is not archived. So the source has been touched within the last seven months, but the published artifacts a user would download are from January 2020.

The licence is GPL-2.0, confirmed by both the repository metadata and the `license` field in the manifest, and it is the copyleft variant, so a modified version distributed to others carries source obligations. This is not legal advice, and for a personal note-taking tool the practical requirement is simply that the licence file stays with the code.

The project links a donation route and a homepage at manifest.app, and issues are tracked on GitHub following an `ISSUE_TEMPLATE.md`.

For an adopter, the practical consequence of the version split is that `manifest.app` and the latest GitHub release may not be the same build, and neither is guaranteed to reflect the current `master`.

Compared with a notes app that syncs and a desktop scratchpad

The realistic alternatives sit at both ends of a spectrum, and the difference in approach is about where the notes live.

A synced notes application stores your data on a server you do not control and adds a client, an account, and a sync protocol. You get multi-device access and backup, and you give up the guarantee that nothing leaves the browser. Manifest's pitch is that guarantee: no connection to a server, no data sent outside the browser, and therefore no account and no network dependency.

A desktop scratchpad, by contrast, is a local file or a local app with its own storage, and it is closer to Manifest than the synced app is. The difference is that a scratchpad is a text buffer or a small editor, whereas Manifest is a spatial board where position and size carry meaning, and where creating a note takes a single drag rather than a new document and a save.

The gap Manifest sits in is a specific one. It is a fast surface for parking a thought, a link, a fragment, with no friction between having the thought and recording it. That is a real niche, and the local-only design serves it directly, since a scratch surface that phoned home would be a different and worse product for some purposes.

What you give up is the entire infrastructure of note keeping. No search across old boards, no tags, no linking between notes, no revision history, no export, no sync between a laptop and a phone, and no recovery when the browser profile is reset. The grid and the drag are the whole feature set, and a reader should judge the project on whether that is enough, rather than on how a full notes system compares.

Editorial conclusion

Use Manifest if you want a frictionless place to park notes in a browser tab, you value the guarantee that nothing is transmitted, and you are comfortable maintaining the project yourself. Do not adopt it if you need mobile support, a browser extension, or shared or synced notes, since the README rules those out. Verify first that the release you install matches the browser you use, because the last tagged release is v1.1.0 from 2020-01-17 while the manifest in the repository reads 1.1.1, and the last push was on 2026-04-02.

Frequently asked questions

Official sources

1. jonathontoon/manifest on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases