About this tier list maker
A board of tier rows, a tray for anything you have not sorted yet, and one interaction model that works identically with a mouse, a touch screen, or a keyboard. No account, no upload, no template gallery — just a working board.
Why it exists
Tier lists are usually made in an image editor or a template site built around one specific game’s character roster. That is fine if the item set you want already has a template, and awkward the moment it does not — ranking foods, tools, or anything without a pre-made background just does not fit. This tool starts from a blank, working board instead: six default rows, a tray, and the ability to add exactly the tiles you actually want to rank, whether that is typed labels or your own images.
The interaction, and why it is pick-up-then-place
The obvious way to build a sortable board is HTML5 drag-and-drop. The obvious way is also wrong for a tool meant to work on a phone: touch screens do not fire native drag events at all, so a drag-only board silently does nothing for a large share of visitors, and a screen-reader or keyboard-only visitor is locked out of it entirely. Rather than build a mouse-drag experience and then patch a keyboard mode on top as an afterthought, this board has exactly one interaction underneath every input method: pick a tile up, then choose where it goes.
Concretely: click or tap a tile to pick it up, then click or tap a destination — a tier, the tray, or another tile to insert just before it — to place it there. On a keyboard, Tab reaches a tile, Enter or Space picks it up, the arrow keys steer it (up/down between tiers, left/right to reorder within a row), and Enter, Space, or Escape sets it down. Every one of those is the same handful of functions underneath, so there is one code path to get right, not two that can quietly drift out of sync.
How it is built
The board's data — which tiles exist, which tier or the tray each one sits in, and each tier's label, colour and position — is kept as one plain object and updated by a small set of pure functions: move a tile, add or remove a tier, rename it, recolour it, reorder it, clear everything, save it, load it back. None of those functions touch the page directly; they take a board and return a new one. A separate layer reads that object and builds the actual tiles, rows, and buttons with document.createElement and textContent — there is no innerHTML anywhere in this tool, so a tile label you type is never interpreted as markup.
Keeping the board logic separate from the page-building code means the logic can be — and was — run and checked outside a browser entirely, under plain Node, asserting things like “moving a tile removes it from its old tier and appends it to the new one,” “removing a tier returns its tiles to the tray instead of deleting them,” and “saving and reloading a board gives back the same text tiles in the same places.” That is a much more direct way to catch a placement bug than clicking through the UI by hand.
The PNG export works the same way conceptually: rather than pull in a screenshot library to photograph the page, the export function reads the same board object and draws every tier band, label, and tile onto a <canvas> itself — measuring text to decide how many tiles fit on a row before wrapping, then drawing rounded rectangles and, for image tiles, the actual uploaded image, cropped to fit. What downloads is exactly what the code drew, not a photograph of the DOM.
What is saved, and what is not
Every tier's name, colour, and position, plus every text tile and where it sits, is written to this browser's local storage whenever you change something, and read back when you return to the page. That is deliberately narrow: it is this browser, this device, with no account and no server involved, so there is nothing to sync and nothing for a server to lose.
Image tiles are the one thing that does not persist. A picture you upload is turned into a temporary in-page reference (an object URL) so the browser can show it instantly without uploading it anywhere — but that reference is only valid for the current page load, and storing the image data itself in local storage would burn through the small quota browsers give that storage almost immediately, for boards with more than a handful of pictures. Rather than silently fail once that quota is hit, this tool draws a clear line: text tiles persist, image tiles do not, and the page says so before you find out the hard way. Export a PNG before closing the tab if you want to keep a board that includes images.
Honest limits
- Not a template gallery. There is no library of pre-made character rosters or background art to choose from — you build the tile set yourself, from text or your own images.
- No sharing link or multiplayer editing. The board lives in your own browser's local storage. Two people cannot edit the same board live; export a PNG to share the result instead.
- Images are session-only, as explained above — that is a deliberate trade against silently overflowing local storage, not an oversight.
- Nothing to install and nothing sent anywhere, currently: this is a plain static page with no build step, running entirely in your browser.