DEV Community: Bracketly

I Finally Gave Bracketly a Logo That Means Something

Bracketly — Mon, 20 Jul 2026 12:05:30 +0000

I Finally Gave Bracketly a Logo That Means Something

Bracketly has had a favicon since day one — a vaguely hood-shaped abstract mark that, looking back, had nothing to do with the name. It just sat there in the browser tab looking like a placeholder nobody replaced. Today I replaced it.

The new mark

It's just [ ] — two brackets, rendered as rounded stroke paths rather than sharp geometric corners, to match the soft-radius design language already used everywhere else on the site (cards, buttons, pills). Literal, obvious in hindsight, and the kind of thing that should've been there from the start for a site called Bracketly.

It ships in two forms:

A monochrome version for the favicon — theme-aware, so it switches between black and white depending on whether your OS is in light or dark mode, same as the rest of the site already does for text and backgrounds.
A full-color version using the site's existing accent gradient (blue → purple → pink) for the header and anywhere else a full-color mark makes sense.

How it's built

Nothing fancier than two <path> elements with stroke-linecap="round" and stroke-linejoin="round" — the rounded bracket ends come for free from the stroke rendering, no manual arc math needed. The tricky part wasn't the shape, it was the spacing: my first attempt had the two brackets' arms overlapping in the middle, which at a glance just looked like a solid rounded rectangle instead of two distinct brackets. Rendered a preview at actual favicon size (32×32) before shipping anything, since a mark that reads fine at 512px can easily turn into mush at the size it actually gets used.

All the PNG variants (32×32, 512×512, and a 180×180 Apple touch icon for anyone who adds the site to their home screen) are rasterized directly from that one SVG source rather than hand-exported, so there's exactly one file to ever update if the mark changes again.

Small change, but it's the kind of detail that either quietly signals "someone's paying attention here" or quietly signals the opposite. Come take a look.

I Built a Cron Expression Parser Because I Kept Getting the "Day" Fields Wrong

Bracketly — Mon, 20 Jul 2026 11:34:37 +0000

I Built a Cron Expression Parser Because I Kept Getting the "Day" Fields Wrong

Cron syntax has five fields — minute, hour, day-of-month, month, day-of-week — and most people can read the first three just fine. 0 9 * * * is obviously "9am, every day." It's the interaction between the last two fields that trips people up, and it tripped me up enough times that I added a Cron Expression Parser to Bracketly, my free client-side dev tools site.

The gotcha: it's OR, not AND

Here's the thing that isn't obvious from staring at 0 0 1 * 1: if you read it left to right, you might assume it means "midnight, on the 1st of the month, AND on a Monday" — i.e. only fires when the 1st happens to land on a Monday.

That's wrong. Standard cron semantics say: when both day-of-month and day-of-week are restricted (neither is a bare *), a date matches if it satisfies either one. So 0 0 1 * 1 actually fires at midnight on the 1st of every month, and separately every Monday. If you wanted "only when the 1st is a Monday," cron can't directly express that at all.

This isn't a bug anywhere — it's just how POSIX cron has always worked — but it's exactly the kind of thing you forget between the few times a year you write a cron expression, and get wrong silently until a job fires on a day you didn't expect.

What the tool does

Paste a cron expression (or one of the @daily / @hourly / @weekly shortcuts) and it gives you:

A plain-English explanation, written to make the OR-not-AND behavior explicit rather than paper over it
The next 5 times the schedule will actually fire, computed from your current time
Inline validation — a field like 99 * * * * gets a specific "value out of range" error instead of just silently doing something unexpected

Like every tool on Bracketly, it's 100% client-side — the parsing and date math happen in your browser, nothing is sent anywhere. It supports the standard field syntax (*, ranges like 1-5, steps like */15, comma lists like 1,15), though numeric fields only for now — no MON/JAN-style names yet.

If you've ever second-guessed whether your deploy schedule actually means what you think it means, it's free and takes about ten seconds to check: bracketly.pages.dev/tools/cron-parser.

Cloudflare's "Autoconfig" Bot Quietly Broke My Static Site's Deploy — Here's What Happened

Bracketly — Mon, 20 Jul 2026 06:08:39 +0000

Cloudflare's "Autoconfig" Bot Quietly Broke My Static Site's Deploy — Here's What Happened

A few days ago, Cloudflare's cloudflare-workers-and-pages[bot] opened a pull request on Bracketly's repo, titled "Add Cloudflare Workers configuration." It sat there unmerged while I worked on other things. Today I merged it without thinking too hard about it — it's from Cloudflare's own bot, on a project already hosted on Cloudflare Pages, seemed safe enough.

It took the site down.

What the PR actually did

It added the @astrojs/cloudflare adapter to astro.config.mjs, generated a wrangler.jsonc, and updated package.json. The framing in the PR description is "configures your project for Cloudflare Workers deployment," which sounds like a reasonable modernization — Workers is Cloudflare's newer, more capable runtime.

The problem: Bracketly is a 100% static, client-side site. Every "tool" on it (JSON formatter, Base64 encoder, hash generator, etc.) runs entirely in the browser — there was never a server-rendering need to justify a Workers adapter in the first place.

Adding the adapter restructured the build output. Before: a flat dist/ with index.html at the root, exactly what a plain static-file deploy expects. After: dist/client/ (the actual site) and dist/server/ (a Workers runtime bundle), because the adapter assumes you want on-demand server rendering alongside static assets.

Why it "succeeded" while actually being broken

My existing GitHub Actions deploy step ran wrangler pages deploy dist — the same command that had worked for weeks. It reported success. The build succeeded. The deploy step reported "Deployment complete." Every automated signal said everything was fine.

Wrangler had actually detected the new dist/client/wrangler.json and silently redirected the deploy target from dist to dist/client on its own — a "helpful" auto-detection feature that meant the command exit code was misleading. It genuinely uploaded files and genuinely returned success. It just wasn't obviously communicating that the actual site paths (/, /tools/whatever, the sitemap) were now 404ing.

I only caught it because I happened to run a manual curl against the live homepage right after the merge and got nothing back where a title tag should be.

The fix

git revert -m 1 <merge-commit>, rebuild locally to confirm dist/index.html exists again (not nested), push. Total downtime: a few minutes, only because I was actively watching for it.

The actual lesson

Automated "helpful" configuration bots — especially ones with commit/PR access to your deploy pipeline — don't know your project's actual architecture. This one assumed "Cloudflare Pages project" implies "wants Workers/SSR," which is a reasonable default guess but was flatly wrong for a purely static site. A green checkmark on a CI deploy step is not the same thing as "the site actually works" — it just means the command didn't throw a non-zero exit code. Worth an actual curl against production after any deploy-pipeline change, automated or not, regardless of how official-looking the bot that proposed it is.

The Silent Cloudflare Pages Bug That Was Quietly Hurting My SEO

Bracketly — Mon, 20 Jul 2026 05:55:33 +0000

The Silent Cloudflare Pages Bug That Was Quietly Hurting My SEO

While building a broken-link checker for Bracketly (a small free dev-tools site), I found something I wasn't expecting: every nonexistent URL on the site — /literally-anything-i-typed, /tools/does-not-exist, whatever — was returning HTTP 200, with the homepage's content, instead of a 404.

Why this happens

Cloudflare Pages has a fallback behavior for unmatched routes: if your deployed site has no 404.html, it serves index.html for any path it can't otherwise resolve — but critically, it does this with a 200 status code, not 404. This is the classic SPA-router pattern (makes sense for a client-side-routed React/Vue app where you want every path to load index.html and let JS take over routing). It's the wrong default for a plain static multi-page site, and if you never explicitly add a 404.html, you get it silently, with zero warning.

I only noticed because I was building a script to curl every URL in my sitemap and flag non-200 responses — and a deliberately-broken test URL came back green.

Why it's worse than it looks

This is what's sometimes called a "soft 404" — a page that should be an error but returns success. Search engines treat this specially, and not kindly:

Google's crawler explicitly detects soft-404 patterns (repeated identical content served at different URLs with a 200 status) and can flag the pattern site-wide, not just the one URL
Every broken/mistyped/old link pointing at your site becomes a duplicate-content page in Google's eyes, all serving the same homepage
It dilutes whatever ranking signal your actual homepage has, since Google now sees N copies of it at different URLs

For a site that had literally zero custom 404 handling, this meant any crawled dead link — a typo'd URL, an old removed page, a bot probing random paths — was quietly generating homepage duplicates in the index.

The fix

Trivial once you know to look for it. In Astro (or basically any static site generator), you just need a page that generates 404.html:

---
// src/pages/404.astro
import BaseLayout from '../layouts/BaseLayout.astro';
---
<BaseLayout title="Page Not Found" description="...">
  <h1>404</h1>
  <p>This page doesn't exist.</p>
</BaseLayout>

Astro (and most SSGs) automatically emits this as dist/404.html, and Cloudflare Pages automatically serves it with a genuine 404 status for any unmatched route once it exists — no config needed, just the file being present.

$ curl -o /dev/null -w "%{http_code}" https://example.com/nonexistent-page
# before: 200
# after:  404

The lesson

If you're deploying a static site to Cloudflare Pages, Vercel, Netlify, or similar — check right now whether a random broken URL on your site returns 404 or 200. It's a two-second check and a five-minute fix, but it's exactly the kind of thing that never shows up unless you go looking, since the page looks completely normal (it's literally rendering your homepage) — there's no visible error to notice.

Source for the actual fix: https://github.com/GRimkiller360/bracketly

I Implemented MD5 From Scratch in JavaScript (Because Web Crypto Won't)

Bracketly — Fri, 17 Jul 2026 09:04:35 +0000

I Implemented MD5 From Scratch in JavaScript (Because Web Crypto Won't)

While building Bracketly — a small set of free, client-side developer tools — I hit an annoying gap while writing the hash generator: the browser's native crypto.subtle.digest() supports SHA-1, SHA-256, SHA-384, and SHA-512, but not MD5.

That's deliberate. MD5 is cryptographically broken — collisions can be deliberately engineered — so the Web Crypto API spec simply doesn't include it. But MD5 is still one of the most-searched hash algorithms, because it's everywhere in non-security contexts: file integrity checksums, legacy system compatibility, cache keys, dedup fingerprints. People still need to compute it, even though nobody should use it for anything security-sensitive anymore.

So: no native API, tool still needs to support it, only option left is implementing the algorithm myself.

The algorithm, briefly

MD5 processes a message in 512-bit (64-byte) chunks through four rounds of 16 operations each — 64 operations total per chunk — each round using a different nonlinear function (F, G, H, I) mixing three of four 32-bit state words, plus a precomputed constant table K (the integer parts of the sines of 1 to 64, in radians) and a set of per-round left-rotation amounts.

The message has to be padded first: append a single 1 bit, then zero bits until the length is congruent to 448 mod 512, then append the original bit-length as a 64-bit little-endian integer. Get this padding wrong by even one byte and every hash silently comes out wrong — there's no error, just garbage output that happens to be valid-looking hex.

Here's the padding and main compression loop:

function md5(str) {
  function rotl(n, s) { return (n << s) | (n >>> (32 - s)); }
  const K = new Uint32Array([
    0xd76aa478, 0xe8c7b756, 0x242070db, 0xc1bdceee, /* ...64 total */
  ]);
  const S = [7,12,17,22, 7,12,17,22, 7,12,17,22, 7,12,17,22,
             5, 9,14,20, 5, 9,14,20, 5, 9,14,20, 5, 9,14,20,
             4,11,16,23, 4,11,16,23, 4,11,16,23, 4,11,16,23,
             6,10,15,21, 6,10,15,21, 6,10,15,21, 6,10,15,21];

  const msg = new TextEncoder().encode(str);
  const origLenBits = msg.length * 8;
  const padLen = (msg.length % 64 < 56) ? (56 - msg.length % 64) : (120 - msg.length % 64);
  const padded = new Uint8Array(msg.length + padLen + 8);
  padded.set(msg);
  padded[msg.length] = 0x80;
  const view = new DataView(padded.buffer);
  view.setUint32(padded.length - 8, origLenBits >>> 0, true);
  view.setUint32(padded.length - 4, Math.floor(origLenBits / 0x100000000), true);

  let a0 = 0x67452301, b0 = 0xefcdab89, c0 = 0x98badcfe, d0 = 0x10325476;

  for (let chunk = 0; chunk < padded.length; chunk += 64) {
    const M = new Uint32Array(16);
    for (let i = 0; i < 16; i++) M[i] = view.getUint32(chunk + i * 4, true);
    let A = a0, B = b0, C = c0, D = d0;
    for (let i = 0; i < 64; i++) {
      let F, g;
      if (i < 16)      { F = (B & C) | (~B & D);        g = i; }
      else if (i < 32) { F = (D & B) | (~D & C);        g = (5 * i + 1) % 16; }
      else if (i < 48) { F = B ^ C ^ D;                 g = (3 * i + 5) % 16; }
      else             { F = C ^ (B | ~D);              g = (7 * i) % 16; }
      F = (F + A + K[i] + M[g]) >>> 0;
      A = D; D = C; C = B;
      B = (B + rotl(F, S[i])) >>> 0;
    }
    a0 = (a0 + A) >>> 0; b0 = (b0 + B) >>> 0; c0 = (c0 + C) >>> 0; d0 = (d0 + D) >>> 0;
  }
  // ...serialize a0-d0 as little-endian hex
}

The trickiest part wasn't the algorithm itself, it was getting the endianness right — MD5 spec is little-endian throughout (message word loading, final digest byte order), which is easy to get backwards if you're used to SHA's big-endian convention. Get it backwards and you get a hash that's wrong in a way that's hard to spot just by eyeballing it (still 32 hex chars, still looks plausible).

Verifying it

Never trust a from-scratch crypto implementation without checking it against known-good vectors. RFC 1321 (and general convention) gives:

md5("")    → d41d8cd98f00b204e9800998ecf8427e
md5("abc") → 900150983cd24fb0d6963f7d28e17f72
md5("The quick brown fox jumps over the lazy dog") → 9e107d9d372bb6826bd81d3542a419d6

All three matched on the first attempt after fixing the endianness bug above — which is a relief, because subtle bugs in hash implementations are exactly the kind of thing that pass casual testing and then produce wrong output on some inputs.

Where it ended up

It's live as one of the tools on Bracketly alongside SHA-1/256/512 (which just call crypto.subtle.digest directly, no reinventing needed there). Everything runs client-side — nothing typed in ever leaves the browser, which is the whole point of the site: a handful of free developer utilities (JSON formatter, Base64, JWT decoder, URL encoder, UUID generator, regex tester, color converter, timestamp converter) with no backend, no accounts, no tracking.

Source is on GitHub if you want to see the rest: https://github.com/GRimkiller360/bracketly