A landing page, a small business site, a portfolio. The code is the easy part; the afternoon disappears into a hundred small decisions that each need a tool you don't want to install. This is the order those decisions tend to arrive in, and what to do about each one.
1. The palette, and the contrast check that saves a redesign
Start in the Color Picker with one colour you're committed to — a brand colour, or just something you like. The harmony generators build the rest around it:
- Analogous (neighbours on the wheel) for a calm, cohesive scheme where nothing fights. Good default for content-led sites.
- Complementary (opposite) when you need one accent that genuinely pops — a single call-to-action button on an otherwise quiet page.
- Triadic for something more energetic, which works when you have distinct sections to separate and know how to keep it restrained.
Then use the contrast checker, and use it before you build anything, not after. It scores foreground-on-background pairs against the WCAG thresholds: 4.5:1 for normal body text to pass AA, 3:1 for large text, 7:1 for AAA.
This is the step people skip and regret. Mid-grey body text on a white background — the look every minimal design tutorial pushes — routinely lands around 3:1 and fails outright. It looks elegant on a calibrated monitor in a dark room and becomes unreadable on a phone outdoors, which is where a large share of your visitors will be. Discovering it after you've built twelve components is a genuine redesign; discovering it now is a nudge on a slider.
Export as CSS custom properties and paste the block straight into your stylesheet. Having the palette as variables from minute one is what stops six near-identical blues accumulating in your CSS by the end of the day.
2. Placeholder text that doesn't flatter your layout
Next, fill the thing. The Lorem Ipsum Generator does classic Latin, plus hipster, corporate and bacon variants, by words, sentences or paragraphs.
The reason to use generated filler rather than typing "Heading here" and "some text" is that placeholder text is a test, and a lazy one tells you nothing. Real content is uneven — one product name is 8 characters, the next is 40. If every card in your grid gets three tidy words, the layout will look perfect and then break the first day someone enters real data.
So generate deliberately uneven content. Fill one card with two words and the next with forty. Set a heading to a single word and its neighbour to a twelve-word sentence. What you're looking for is where the grid stops aligning, where a button's label wraps to two lines, where an ellipsis is needed and isn't there. Every one of those is cheaper to fix now.
The non-Latin variants have a specific use: showing a client a draft. Classic lorem ipsum reads as "unfinished" and invites "when will the real text be ready?"; corporate filler reads closely enough to plausible copy that the conversation stays on the layout, which is what you actually wanted feedback on.
3. Metadata that fits the space Google gives it
Before you publish, the title and meta description. Both get truncated, and truncation is decided by pixel width rather than a hard character count, but the working guidance is 50–60 characters for a title and 150–160 for a description.
Paste each into the Word Counter and read the character count. This takes ten seconds and it is the difference between a search result that makes its case and one that ends mid-sen…
While you're there, run your main body copy through it too. Two numbers are worth a look:
- Readability. The Flesch reading-ease score is a rough proxy for sentence length and word complexity. Aim for 60 or above on marketing copy — that's roughly plain-English territory. A low score usually means one long sentence you can split in two.
- Keyword density. Useful as a warning, not a target. If a phrase is appearing at 5% you've written something that reads badly to a human and looks like keyword stuffing to a search engine. There's no density to aim for; there's just a level that means you should rewrite.
The reading-time estimate is worth putting on the page itself if you're publishing anything long. It measurably reduces bounce, because it lets someone decide to come back later rather than leaving.
4. The API response you can't read
At some point you'll hit an endpoint and get back 40KB on a single line. The JSON Formatter is for that moment: beautify to get indentation, tree view to collapse the branches you don't care about, and validation that points at the actual character where it broke rather than saying "unexpected token" and leaving you to hunt.
Two features earn their keep beyond formatting. Diff mode answers "why does staging return something different from production?" faster than reading both. JSONPath queries pull one field out of a deeply nested response without scrolling — the fastest way to confirm the data is actually in there before you go debugging your rendering code.
And minify at the end, if you're embedding JSON in a page or a config: it's a real byte saving on something that gets shipped to every visitor.
Worth knowing: this runs entirely in your browser. API responses routinely contain tokens, keys, email addresses and customer records, and pasting them into an online formatter that posts to a server is a habit that has caused real incidents. Nothing you paste here leaves the tab — check the network panel if you'd rather verify than trust.
5. The QR code, and where it actually belongs
Site's live. The QR Code Generator turns the URL into something printable — and it handles URLs, plain text, WiFi credentials, email addresses and phone numbers, which covers most of what small businesses need.
Where these genuinely work: a menu or a price list on a table; a poster or a shop window; a business card; packaging that links to setup instructions; a WiFi code for guests; an "email us" code on a market stall so nobody has to copy an address into a phone keyboard.
A few practical things that decide whether it scans:
- Contrast and orientation. Dark code on a light background. Inverted codes fail on a lot of scanners, so if you're colouring it to match the palette you just built, keep the code darker than its background and test it on an actual phone before it goes to print.
- Quiet zone. Leave clear space around all four sides. Codes that are cropped tight to a design element are the most common print failure.
- Size. Roughly one centimetre of code per ten centimetres of scanning distance is a decent rule. A code on a shop window being scanned from two metres away needs to be much bigger than people assume.
- Short URLs make simpler codes. More data means a denser grid and a code that needs to be printed larger to stay reliable. It's a real argument for a tidy URL structure.
- Download the PNG at high resolution for anything going to print, and test the printed proof rather than the screen.
The order, and why it's this order
Palette before layout, because contrast failures are structural. Filler before content, because it's a stress test and you want to fail early. Metadata before publishing, because nobody goes back. Formatter when the data fights you. QR code last, when there's a real URL to encode.
Every one of these runs in the browser with nothing to install and nothing to sign up for, which is the entire point — none of them is worth an account, and collectively they're most of an afternoon's friction.