DEV Community: BY L

Privacy-First Patterns for Browser-Based Self-Reflection Tools

BY L — Thu, 13 Aug 2026 11:13:06 +0000

Personal questionnaires look like simple front-end projects, but they raise real design questions about data handling and interpretation. A useful implementation should minimize collection, explain its scoring, and avoid presenting a lightweight result as a diagnosis.

Keep raw answers on the device

If the experience does not need cross-device sync, individual responses can stay in browser memory or local storage. Scoring can run entirely in JavaScript. This supports progress indicators, answer review, and category summaries without sending sensitive selections to an analytics or application server.

The privacy copy should match the implementation. Tell users what remains local, whether anything is persisted, and how they can clear it. Avoid collecting an email merely to reveal a result.

Separate scoring from meaning

A numeric score is a compact summary, not proof of personality, morality, health, or compatibility. The interface should make that limit visible near the result instead of hiding it in a footer. It should also allow people to skip prompts that are uncomfortable.

Test Rice Purity is one example of this pattern: a free browser-local questionnaire paired with transparent score context and privacy-conscious defaults.

Design the follow-up

The most useful questions come after the number: Which prompts felt relevant? Which lacked context? What should remain private? A thoughtful product gives users room to disagree with the output and avoids fixed labels.

These choices are technically modest, but they materially improve trust. Local computation, clear boundaries, and restrained interpretation are good defaults for any self-reflection tool built on the web.

Designing a Browser-Local Image Merge Pipeline Without Uploads

BY L — Wed, 12 Aug 2026 16:24:15 +0000

Combining several images into one canvas looks like a server-side job, but modern browser APIs make a local-first pipeline practical. That choice matters when the source files are screenshots, receipts, product photos, or reference images that users may not want to upload to an unknown processing queue.

Why keep the merge in the browser?

A browser-local workflow has three useful properties:

Privacy: the selected files can stay on the user's device.
Fast feedback: decoding, layout changes, and previews do not wait for a round trip.
Predictable cleanup: closing or reloading the tab releases the in-memory working set instead of leaving a cloud project behind.

Local processing does not remove every risk, but it removes the ordinary image-upload path from the core task.

A practical merge pipeline

The core loop can be small and explicit:

Accept only the image types the interface documents.
Decode each selected file with createImageBitmap() or an Image element.
Normalize orientation and calculate a destination rectangle for every item.
Size one output canvas from the complete layout plan.
Draw backgrounds, gaps, and images in a deterministic order.
Export with canvas.toBlob(), then verify that the blob is non-empty before enabling download.

async function decodeFiles(files) {
  const decoded = [];

  for (const file of files) {
    if (!/^image\/(jpeg|png|webp)$/.test(file.type)) {
      throw new Error('Unsupported image type');
    }

    const bitmap = await createImageBitmap(file);
    decoded.push({ file, bitmap, width: bitmap.width, height: bitmap.height });
  }

  return decoded;
}

The important design decision is to compute the whole layout before drawing. A horizontal merge sums destination widths and uses the tallest destination height. A vertical merge does the inverse. A grid also needs column widths, row heights, gaps, outer padding, and the chosen fit rule. Keeping those values in one plan makes the preview and final export use the same geometry.

Contain, cover, and alignment

Users usually expect one of two fitting modes:

Contain preserves the entire source image and may leave empty space.
Cover fills the destination cell and crops the excess.

Alignment then decides where the image or crop sits: start, center, or end on each axis. These controls should change only the planned source and destination rectangles; the render loop can remain boring. Boring render code is easier to test.

Guardrails prevent browser crashes

Canvas dimensions and memory usage can grow surprisingly fast. A 12,000 by 8,000 RGBA canvas needs hundreds of megabytes before export. Useful protections include:

a documented file-count limit;
a per-file byte limit;
a maximum output edge and total pixel count;
proportional downscaling when the planned output crosses those limits;
closing decoded ImageBitmap objects when they are removed;
revoking temporary object URLs during cleanup.

These limits are part of the product contract, not just implementation details. Show the user when scaling occurs and keep the originals untouched.

Verification should use real files

A merge tool deserves more than a button-click smoke test. Good fixtures use images with known colors and dimensions so the test can check:

the exact output width and height;
the pixel color at each placement boundary;
gap and background colors;
ordering after drag-and-drop;
PNG, JPEG, and WebP signatures;
behavior when a proposed canvas exceeds the safety limit;
the absence of image-upload network requests during the core workflow.

It is also worth testing at a narrow viewport. File cards, reorder controls, export settings, and the preview should remain usable without horizontal overflow.

A working reference

MergeImage is a free browser-local implementation of this approach. It supports horizontal, vertical, and grid merging, plus screenshot stitching, comparison, overlay, image splitting, sprite sheets, and printable contact sheets. The source images are processed in the active browser tab, and the interface exposes the limits before export.

The larger lesson is simple: plan first, render once, measure the actual output, and make privacy claims match the network behavior. Those choices turn a small canvas demo into a tool people can understand and verify.

Resize Images Locally in the Browser: A Privacy-First Workflow

BY L — Thu, 06 Aug 2026 13:45:06 +0000

If an application portal asks for a photo at an exact pixel size or inside a narrow KB range, the easiest solution is not always an upload-and-process API. Modern browsers already provide the primitives needed to do the work locally.

Why local processing matters

Photos and signatures can contain sensitive information. A client-side workflow keeps the source file on the user's device and removes the need to trust a temporary upload pipeline. It also reduces network latency and makes the tool usable on slower connections.

The core steps are straightforward:

Read the selected file with createImageBitmap() or an Image element.
Calculate target dimensions while preserving the aspect ratio.
Draw the bitmap to a canvas.
Export with canvas.toBlob().
Measure the resulting blob size and iterate over quality when a KB target matters.
Show a real preview before download.

async function resizeToWidth(file, width) {
  const bitmap = await createImageBitmap(file);
  const height = Math.round(bitmap.height * width / bitmap.width);

  const canvas = document.createElement("canvas");
  canvas.width = width;
  canvas.height = height;

  const ctx = canvas.getContext("2d");
  ctx.drawImage(bitmap, 0, 0, width, height);

  return new Promise((resolve) => {
    canvas.toBlob(resolve, "image/jpeg", 0.9);
  });
}

Pixels and KB are different constraints

Changing dimensions affects the number of pixels. Changing JPEG or WebP quality affects compression. When both constraints apply, solve dimensions first, then adjust output quality and measure the actual blob after every encode. Avoid claiming success from a quality percentage alone because visually similar files can compress very differently.

A useful browser tool

IncreaseImages follows this local-first model. It can increase image dimensions or work toward a target KB range for JPG, PNG, and WebP files. The selected image stays in the browser, and the user can preview and download the measured result.

This approach is especially useful for application photos, scanned signatures, and other images where privacy, exact dimensions, and predictable file size matter more than server-side convenience.

Final checks before download

Verify width and height in pixels.
Verify the measured byte size, not an estimate.
Inspect edges and text at 100% zoom.
Keep the original file as a fallback.
Recheck the destination portal's latest rules before submission.

Browser-local image processing is a small architectural choice that creates a noticeably calmer user experience: faster feedback, less data exposure, and results that can be checked before anything leaves the device.

A Privacy-First Architecture for a Browser-Based Rice Purity Test

BY L — Thu, 06 Aug 2026 12:03:23 +0000

A sensitive questionnaire does not need a server-side answer store. For a recent browser project, I treated data minimization as a product requirement rather than a policy-page promise.

The result is Test Rice Purity, an independent adults-only implementation of the familiar 100-question checklist.

Core design choices

Local state: checked items remain in the browser.
Transparent scoring: the score is 100 minus the number of checked items.
No account gate: users can complete the flow without creating a profile.
Clear-data control: progress can be removed on shared devices.
Safe result framing: the score is for entertainment and self-reflection, not a clinical or moral judgment.

Sharing without leaking answers

A share action should be explicit and should contain only the information the user chose to publish. The individual checklist answers are not needed for a result card or a friend challenge, so they should never be placed in an analytics event or a readable query string.

What this improves

Keeping the calculation local reduces the data surface, makes the privacy promise testable, and lets the interface be useful even without sign-in. It also forces clearer UX: users can see how their score works and can remove local progress at any time.

You can review the live implementation at Test Rice Purity. It is not affiliated with Rice University.

Designing a Fair Browser-Local Word-Grid Practice Loop

BY L — Thu, 06 Aug 2026 10:54:44 +0000

A good word-grid game is not only a dictionary wrapped around a square of letters. The interesting design work happens in the feedback loop: how a player scans the board, tests a path, understands a miss, and returns for another attempt without being pushed into an account or a leaderboard.

I recently used Squaredle 2 as a small case study for this kind of browser-first practice experience. It is an independent word-grid project with Daily, Express, and Unlimited modes, and it keeps progress in the browser instead of requiring a sign-up.

1. Make the path rule visible

Adjacent-letter games usually allow eight directions while preventing one tile from being reused inside the same word. That sounds simple, but the interface has to explain it through behavior.

A useful implementation keeps the selected path visible, rejects a repeated tile immediately, and gives the same result whether the player drags, taps, or types. The visible path is not decoration: it is the proof that the game understood the player's intent.

2. Separate target words from bonus words

If every dictionary word counts equally, a board can feel arbitrary. A clearer model has a curated target list for progress and a broader bonus list for valid discoveries. Players then understand what completion means without being punished for finding a legitimate word that was not part of the main route.

The important part is to label the distinction. A bonus should feel like recognition, not like a hidden exception.

3. Keep practice local and reversible

For a lightweight puzzle, an account can create more friction than value. Local storage is enough for daily progress, streaks, mode history, and the current board. It also makes the privacy promise easy to explain: progress stays on the device and can be cleared by the player.

Local persistence needs a versioned key and defensive parsing. A corrupted value should reset gracefully rather than breaking the game.

4. Design multiple time horizons

One daily board builds a habit, but it is not the only useful session shape.

Daily gives everyone the same board.
Express lowers the time commitment with a smaller grid.
Unlimited lets a motivated player keep practicing.

These modes share the same interaction model while serving different moments. That is more coherent than adding unrelated mini-games just to increase session time.

5. Treat accessibility as an input model

Pointer dragging alone is fragile. A keyboard route, readable focus states, descriptive board labels, and large touch targets make the core mechanic usable across devices. Rotation and fullscreen controls should preserve the logical board state instead of restarting it.

The best accessibility work also improves debugging because every state transition becomes explicit.

6. Give hints that teach scanning

A complete answer reveal ends the search. A better hint can expose the starting letter, word length, or one early path segment. The player still performs the recognition work, so the hint becomes part of the learning loop.

That principle generalizes beyond games: good assistance reduces uncertainty without removing the meaningful action.

A practical checklist

Before publishing a word-grid experience, I would test:

repeated-tile rejection;
diagonal and edge paths;
pointer, touch, and keyboard parity;
persistence after refresh;
deterministic daily selection;
small-screen layout;
clear target-versus-bonus feedback;
an honest independent-product disclosure.

A small browser game can be technically modest and still be thoughtfully designed. The durable value comes from making every rule visible, every saved state reversible, and every next attempt easy to understand.

Reverse Word Puzzles: Why Preserving Options Beats Maximum Information

BY L — Thu, 06 Aug 2026 08:56:05 +0000

Reverse word puzzles use a familiar five-letter format but invert the objective: the hidden word is the one answer you must avoid. That change turns ordinary deduction into a problem of option preservation.

Why the usual strategy breaks

In a standard word puzzle, a strong guess removes as many candidates as possible. In a reverse game, removing too many candidates can be risky. If only one legal word remains and it is the hidden answer, the run is over.

A better evaluation asks two questions at once:

How much information does this guess reveal?
How many safe continuations will still exist afterward?

The best move often keeps several branches alive, even when another word would reveal more information immediately.

Three useful tactics

1. Separate similar endings

When several candidates share a suffix, choose a probe that tests their distinguishing letters in new positions. The goal is to split the set without committing to the obvious completion.

2. Treat repeated letters as information

A repeated letter can look wasteful in an ordinary opener, but it may be valuable when one-versus-two occurrences determine whether multiple escape words remain.

3. Delay forced patterns

If a guess would lock four positions and leave a single legal completion, it may be strategically worse than a less direct word that preserves two or three paths.

A browser tool for practicing

Dont Wordle is a free reverse word puzzle with a daily challenge, unlimited games, an archive, a solver, and strategy references. It runs directly in the browser and makes it easy to compare how different guesses reshape the candidate set.

The solver is useful for analysis because it exposes the decision tree behind a move. You can test whether a guess merely gains information or actually leaves a healthier set of safe next turns.

The broader lesson

Reverse word games are small planning systems. They reward players who resist the most obvious answer, track branching possibilities, and think one move beyond the current clue pattern. The key habit is simple: do not optimize only for certainty; optimize for the quality of the choices that remain.

A privacy-first way to explore love language results in the browser

BY L — Wed, 05 Aug 2026 12:53:38 +0000

A privacy-first way to explore love language results in the browser

Reflection tools can be useful, but the questions and results may feel personal. That makes the storage model part of the product experience, not just an implementation detail.

I built KindredCue as a small, browser-local love language test. It is free to use and does not require an account or email address. The questions help people notice how they tend to express and receive care, while the result is kept on the device instead of being turned into another online profile.

The local-first approach also changes the conversation around sharing. Someone can take the test privately, decide what the result means to them, and then choose whether to discuss it with a partner, friend, or family member. The tool is a prompt for reflection, not a diagnosis or a label.

For a simple example of this pattern, try the KindredCue love language test.

Building a Browser-Local Reverse Wordle Game

BY L — Wed, 05 Aug 2026 07:57:20 +0000

Most word games reward a guess that gets closer to the answer. I wanted to explore the opposite constraint: what if solving too early is the mistake?

That idea became Dont Wordle, a small browser-local reverse Wordle puzzle. The goal is not to guess the hidden word as quickly as possible. Each row must remain a legal guess while the player keeps enough options open to finish the board.

The interesting constraint

The game has three pieces of state that matter:

the current board and its legal guesses
the remaining candidate paths
the player’s saved progress for the daily challenge

Keeping that state in the browser makes the core loop fast and private. A player can open the page, play without an account, undo a move, and return later without a server session.

The design also changes the feedback loop. In a normal Wordle-style game, green letters feel like progress. In a reverse puzzle, too much information can close the remaining paths. The useful question after every row is: “Did this guess preserve a route to the end?”

Small UX details carry the game

A reverse rule is easy to explain but easy to misunderstand in play, so the interface needs to make the constraint visible. I added a legal-guess counter, an undo action, a daily challenge state, and clear feedback when a move would make the board unsolvable.

Those details are more important than adding a large feature list. The player should be able to understand why a guess failed and try another line immediately.

Why browser-local was a good fit

This kind of game does not need an account system for its first version. Local persistence keeps the product lightweight, avoids collecting unnecessary player data, and makes the daily loop work on a phone or a desktop browser.

The result is available as Dont Wordle, a free reverse word puzzle you can try directly in the browser.

The broader lesson for small web games is that a single changed rule can create a different strategy space. The engineering challenge is then to make that rule legible through state, feedback, and a very short path from opening the page to making the first move.

Using HSB sliders to make a playful color-memory game

BY L — Wed, 05 Aug 2026 06:21:18 +0000

I built Toon Tone, a free cartoon color guessing game for practicing color memory in a lightweight browser experience. The game uses HSB sliders so hue, saturation, and brightness are easy to reason about while matching a character color.

The project is intentionally small and shareable: it includes daily prompts, instant feedback, and shareable scores without requiring an account.

Play Toon Tone

I would love feedback on the interaction design and on whether HSB controls feel more intuitive than RGB inputs for this kind of warm-up game.

Designing a Browser-Local Eight-Board Word Puzzle

BY L — Mon, 03 Aug 2026 17:06:47 +0000

Why an eight-board puzzle needs a different rhythm

Most five-letter word games ask you to optimize one board. An eight-board variant turns every guess into a small information-sharing system: the same word is tested against eight answers, and the feedback arrives in parallel. That changes the best strategy from “find the answer” to “reduce uncertainty across the grid.”

Octordle Pro is a free browser-local implementation of that format. It offers Daily and Unlimited modes, keeps progress and statistics locally, and includes shareable challenge links. The product is useful as a small example of how a web game can stay interactive without requiring an account or a paid API.

The data problem is the game

Each board can be represented as a pattern, a set of excluded letters, and a set of misplaced letters. A strong opening word maximizes coverage across those sets. Once one board becomes constrained, the next guess should be chosen by its expected value for the other seven, not just by how close it looks on the first board.

That creates three practical rules:

Start with distinct, common letters so the first result teaches you something on many boards.
Keep confirmed and excluded letters separate; a yellow letter is evidence about position, not permission to reuse it anywhere.
Use a probe guess when it can eliminate several candidate families at once, even if it is unlikely to solve a board immediately.

Why browser-local matters

A browser-local game can keep statistics and preferences in local storage, load quickly, and avoid sending a player's guesses to a server. The trade-off is that progress is device-specific, so a clear shareable challenge URL is useful when you want to compare a round with someone else.

The most satisfying rounds come from treating the eight boards as one system. Broad coverage early, careful bookkeeping in the middle, and focused cleanup at the end make a large grid feel manageable.