DEV Community: Khatai Huseynzada

What a chess parser taught me about trusting user input

Khatai Huseynzada — Fri, 10 Jul 2026 17:04:49 +0000

I build a chess diagram tool. You type a position, it draws a board, you export a nice image. Simple.

The whole thing runs on one string: the FEN. It looks like this:

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

That's the starting position. Eight ranks separated by slashes, a letter per piece, a number for empty squares. Harmless.

Except that string doesn't always come from a keyboard. It comes from a URL somebody shared. From localStorage that could have been edited. From a cloud row that synced back down. From a database API I don't control. Every one of those is a door, and for a while I was leaving them open because the input looked boring.

Here's what I learned closing them.

"It's just a string" is the lie

The trap with input like a FEN is that it feels too small to be dangerous. It's 40-ish characters of chess notation. What's the worst it can do?

But your code doesn't treat it as 40 characters. It parses it. It stores it. It stringifies it into a filename. It renders it back into the DOM. Each of those steps trusts the string a little more than the last, and the string never earned that trust — you just assumed it.

So I stopped asking "is this valid chess?" and started asking "what happens if this is not what I expect, at every single place I touch it?"

Door 1: length, before anything else

The first thing a parser should do is refuse to parse.

A real FEN maxes out around 90 characters. So the cap comes first, before any splitting or looping:

const MAX_FEN_LENGTH = 93;

function parseFEN(fenString: string) {
  if (!fenString || typeof fenString !== 'string')
    throw new FENParseError('Invalid FEN string');
  if (fenString.length > MAX_FEN_LENGTH)
    throw new FENParseError('FEN string exceeds maximum length');
  // ...only now do we start reading it
}

This isn't about chess. It's that any string arriving from outside can be a megabyte, and if the first thing I do is .split() and loop over it, I've handed a stranger the ability to make my main thread chew on garbage. The length check is a bouncer at the door. Cheap, boring, first.

The nice side effect: I enforce the same cap everywhere a FEN enters — the URL handler, the share link, the input field's maxLength. One number, checked at every door, instead of "I'm sure the parser handles it."

Door 2: parsing is validation, not decoration

My early parser was optimistic. It split on /, walked each rank, and mostly assumed the pieces were pieces. If something weird showed up, it kind of... limped along and produced a half-broken board.

That's the worst outcome. Not a crash — a quiet wrong answer that flows downstream.

The fix was to make the parser strict and loud. Every rank has to have exactly 8 squares. Every character is either a digit or a real piece letter, nothing else. Anything off the script throws:

for (const char of row) {
  if (VALID_DIGITS.has(char)) {
    const count = parseInt(char, 10);
    squareCount += count;
    for (let i = 0; i < count; i++) boardRow.push('');
  } else {
    if (!isPieceSymbol(char))
      throw new FENParseError(`Invalid piece character '${char}'`);
    squareCount++;
    boardRow.push(char);
  }
}
if (squareCount !== 8)
  throw new FENParseError(`Rank has ${squareCount} squares instead of 8`);

The rule I follow now: a parser that returns a "kind of okay" result on bad input is a bug generator. Either you get a valid board or you get an error you can catch. There is no third thing.

Door 3: JSON.parse is not a safe way to read stored data

This one actually surprised me.

I sync positions and settings. They live in localStorage and in a cloud row, and both come back as strings I JSON.parse. Standard stuff. But JSON.parse will happily reconstruct anything in that string, including keys you never want to see:

{ "fen": "…", "__proto__": { "isAdmin": true } }

Parse that naively and, depending on how the object flows through your code, you can end up polluting the prototype every object inherits from. This is a real, named class of bug — prototype pollution — and the entry point is as innocent as "read my saved settings."

So I don't call JSON.parse directly on anything from outside. It goes through one function that strips the poison keys with a reviver and falls back instead of throwing:

const POISON = new Set(['__proto__', 'constructor', 'prototype']);

function safeJSONParse<T>(jsonString: string | null | undefined, fallback: T): T {
  if (!jsonString || typeof jsonString !== 'string') return fallback;
  try {
    const parsed = JSON.parse(jsonString, (key, value) =>
      key !== '' && POISON.has(key) ? undefined : value
    );
    return parsed != null ? parsed : fallback;
  } catch {
    return fallback;
  }
}

Two things I like about this. It drops the dangerous keys instead of trusting the input to be nice. And a broken string gives me the fallback, not an exception halfway through app startup. The rule became simple and absolute: raw JSON.parse on external data is banned in the codebase. Every read goes through this door.

Door 4: sanitize at the boundary, based on where it's going

Here's the part that took me longest to internalize: there isn't one "sanitize" function. Cleaning depends on the destination.

The same user-supplied string might become a filename, a color, or text on the page — and each of those has different things that hurt it.

Going into the DOM as text? Escape the HTML so a <script> stays literal characters:

function sanitizeInput(input: unknown, maxLength = 500): string {
  if (!input || typeof input !== 'string') return '';
  const s = input
    .replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;').replace(/'/g, '&#x27;').replace(/\//g, '&#x2F;')
    .trim();
  return s.length > maxLength ? s.slice(0, maxLength) : s;
}

Becoming a filename? Kill the path separators and reserved characters so a "name" can't climb out of the directory or break the download:

function sanitizeFileName(fileName?: string | null): string {
  if (!fileName || typeof fileName !== 'string') return 'chess-position';
  let s = fileName.replace(/[\\/:*?"<>|&]/g, '-');
  s = s.replace(/\s+/g, '_').replace(/^\.+/, '').replace(/\.+$/, '').trim();
  if (s.length > 100) s = s.slice(0, 100);
  return s || 'chess-position';
}

Being used as a color? Don't "clean" it — allowlist it. Either it matches an exact hex pattern or it's replaced with a default. No trying to fix a bad value:

function isValidHexColor(color: unknown): color is string {
  return typeof color === 'string' && /^#[0-9A-Fa-f]{6}$/.test(color);
}

function sanitizeHexColor(color: unknown, fallback = '#ffffff'): string {
  return isValidHexColor(color) ? color : fallback;
}

That last one is the pattern I trust most: allowlist, don't blocklist. A blocklist is you trying to imagine every bad input. An allowlist is you describing the one shape you accept and rejecting the infinite rest by default. You will lose the imagination game. You won't lose the allowlist game.

The mental model that stuck

I used to think of security as a thing you bolt on — a review at the end, a linter rule, a checklist.

What actually changed my code was a smaller idea: every place data crosses from "outside" to "inside" is a boundary, and boundaries have jobs. The parser's job is to reject anything that isn't a real board. The storage reader's job is to never reconstruct a poison key. The DOM writer's job is to escape. The filename builder's job is to strip paths.

None of these are clever. That's the point. They're boring, they live at the edges, and they mean that by the time a value reaches the interesting part of my app, it has already passed through the right door for where it's headed.

The chess part was incidental. The lesson is: the more harmless your input looks, the more likely you are to trust it without earning it.

This all came out of an open-source chess diagram tool I've been building. If you want to see the parser and the sanitizers in their natural habitat, the repo is chessviewer-org/chess-viewer and the utilities live in their own package, @chessviewer-org/chess-viewer.

I built a Chess Diagram Generator from scratch using React and Raw SVG (0 external chess libraries)

Khatai Huseynzada — Thu, 09 Jul 2026 22:26:31 +0000

Hey everyone! 👋

Over the last 7 months, I’ve been working on a personal project: a fully open-source, privacy-first Chess Diagram Generator called Chess Viewer.

Usually, when developers build chess apps, they rely on heavy libraries like chess.js or react-chessboard. I wanted to challenge myself. So, I built the entire board, FEN (Forsyth-Edwards Notation) parsing, and piece rendering logic completely from scratch using React and Raw SVG.

It mathematically calculates where each SVG piece should go, supports advanced FEN previews, and exports high-quality diagrams.

Tech Stack: React, TypeScript, Vite, PWA.

🔗 Live Demo: https://chessvision.org
💻 GitHub Repo: https://github.com/chessviewer-org/chess-viewer

🔥 Roast My Code! (I need your feedback)

I'm 17 years old and mostly self-taught. Since I built the entire architecture and SVG logic myself without tutorials, I’m 100% sure there are better ways to handle some of the state management and re-renders.

I would absolutely love it if some experienced React developers could check out the repo and roast my code. Tell me what I did wrong or how I can optimize it!

🛠️ Want to contribute? (Good First Issues)

I want to make this a community-driven tool. I've set up several beginner-friendly issues in the repo if you want to make your first open-source contribution or just practice your React skills.

We currently need help with bugs like:

#186 - Piece entrance animation replays on back-navigation
#187 - Export file size estimate does not match actual exported file

Just look for the good first issue or help wanted tags in the repo!

Any feedback, Pull Requests, or stars ⭐ would mean the world to me. Thanks for reading!

7 months building an open-source chess tool. Here's what actually happened.

Khatai Huseynzada — Sun, 28 Jun 2026 16:53:19 +0000

I started this project in December 2025. Not because anyone asked. Not because I saw a gap in the market. Because I compose chess problems as a hobby and every tool I tried to export a diagram with either watermarked the output, required an account, or exported at 72 DPI like it was still 2003.

So I built my own. Seven months later: 5 stars on GitHub, 6 forks, a handful of npm downloads, about $13 spent on hosting.

That's the whole story, numbers-wise.

Why I kept going

The tool actually works. That sounds like a low bar, but a lot of side projects don't clear it.

You paste in a FEN string, configure the board however you want — colors, piece set, whether to show coordinates — and export a PNG at up to 1200 DPI with real physical dimensions. You tell it "6cm board at 600 DPI" and it gives you a file you can drop straight into a print layout. No watermark. No account. No ads.

I added cloud sync, batch export (up to 10 positions as a ZIP), a FEN history, a position database search. Probably spent too long on some of that. But the core thing works exactly as I wanted it to.

The bugs that actually taught me something

Safari has a GPU memory limit on canvas elements that Chrome doesn't. If you don't reset canvas.width = 0; canvas.height = 0 after every blob export, iOS will crash — silently, with no useful error. I hit this, spent a while confused about why it only happened on iPhones, then traced it down and fixed it. Now it's a documented invariant in the codebase: you touch the canvas export path, you reset the dimensions after. No exceptions.

The FEN parser has co-located unit tests and a rule: every change requires a new test case. It sounds strict but it's saved me twice.

These are the parts I'm actually proud of.

What I got wrong

I thought if the tool was good, people would find it. That's not how it works.

GitHub has no discovery mechanism. npm sorts by download count — which means new packages are invisible by default. The people who need your tool don't know it exists and aren't searching for it by name.

I also built for a narrow audience without fully accepting what that meant. Chess composers are a small group. Most chess players don't need to export diagrams to print. I knew this going in, but I still somehow expected more traction.

The npm package

A month ago I extracted the rendering core into a separate package: @chessviewer-org/chess-viewer. Zero dependencies, works in Node.js, Deno, Bun, and the browser. Pure SVG output — no DOM, no canvas.

import { generateDiagram } from '@chessvision-org/chess-vision';

const svg = generateDiagram({
  fen: 'rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1',
  size: 400,
  showCoords: true,
});

The idea was that even if the web app never takes off, the package might be useful to someone building a chess blog or generating diagrams server-side. It's only been on npm a week so I have no idea yet.

Where I'm at

The code is the best it's ever been. The tool does what I wanted it to do. I've learned more about Canvas, Safari memory behavior, Supabase RLS, and FEN parsing edge cases than I ever would have otherwise.

But I haven't figured out how to reach the people who would actually use it. That part is harder than the technical stuff. I'm more comfortable writing a parser than writing a cold message to a chess magazine editor.

I'm going to keep working on it. Just with less time on features and more time actually talking to people.

Repo: github.com/chessviewer-org/chess-viewer

Tool: chessvision.org

Package: @chessviewer-org/chess-viewer

If you've been through something similar — built something real, got nowhere with distribution — I'd like to hear what you did.

Stop Using console.log(): 5 Hidden Chrome DevTools Superpowers 🚀

Khatai Huseynzada — Thu, 16 Apr 2026 19:25:27 +0000

Let's be honest: as web developers, whether we are working on the front-end or back-end, we spend half of our lives staring at the browser's Developer Tools. However, the vast majority of us only scratch the surface of what this massive Swiss Army knife can actually do.

If your primary debugging strategy is still littering your codebase with console.log("here 1") and console.log("data", data), you are losing valuable time.

Let's dive into 5 lesser-known Chrome DevTools features that will instantly speed up your workflow and make your debugging process a lot less painful.

1. Convert Network Requests to Code Instantly ("Copy as Fetch") 🌐

Imagine a complex API request is firing on your website, and you want to test that exact same request in your terminal, a Node.js script, or Postman. Manually typing out all the headers, authorization tokens, and stringified payloads is a nightmare.

The Hack:

Go to the Network tab in DevTools.
Right-click the request you want to duplicate.
Hover over Copy and select Copy as fetch (or Copy as cURL).

Boom! The browser instantly generates the exact code needed to replicate that request. You can paste it directly into your code editor or console and tweak it as needed.

2. Visualize Arrays and Objects with `console.table()` 📊

When fetching an array of objects from an API, a standard console.log() results in a deeply nested, messy output in the console that requires endless clicking to expand.

The Hack:
Swap out your console.log(data) for console.table(data).

The browser will automatically parse your array of objects and render it as a beautifully formatted, highly readable table. Even better? You can click the column headers in the console to sort the data!

3. Turn Your Browser into a Live Text Editor (`designMode`) ✍️

A designer or client asks you to "quickly tweak the wording" on a landing page to see how it looks. Switching back to your IDE, finding the exact text node, changing it, and waiting for the page to reload is incredibly tedious.

The Hack:
Open your Console and type this magic spell:

document.designMode = "on";

Hit Enter. Now, you can click on any text element on the webpage and edit it live, exactly like a Microsoft Word document. It’s an absolute lifesaver for rapid UI testing and typography adjustments.

4. Lightning-Fast DOM Access in the Console (`$0`) ⚡

You are inspecting an HTML element in the Elements tab and want to manipulate it using JavaScript in the console. Most developers waste time writing document.querySelector('.my-long-class-name') to grab it.

The Hack:

Simply click on any element in the Elements tab so it's highlighted.
Switch over to the Console tab.
Type $0 and hit Enter.

That's it! $0 is a magic variable that holds the reference to the most recently inspected element. You can immediately start calling methods on it, like $0.classList.add('hidden').

(Bonus: DevTools remembers your history! You can use $1, $2, etc., to reference previously inspected elements).

5. Debug Loops Painlessly with Conditional Breakpoints 🛑

You have a for loop that iterates 1,000 times, but a bug only occurs when i === 499. If you drop a standard breakpoint inside the loop, execution will pause on the very first iteration, and you'll have to click "Resume" 499 times. No thanks.

The Hack:

Go to the Sources tab.
Right-click on the line number where you want to pause.
Select Add conditional breakpoint...
Type your condition (e.g., i === 499 or user.role === 'admin').

Execution will completely ignore the breakpoint unless your exact condition evaluates to true. This reduces your bug-hunting time from hours to seconds.

Wrapping Up

Chrome DevTools is much more than just a place to read error messages. By incorporating these small hacks into your daily routine, you'll drastically reduce friction in your development process.

Which DevTools feature can you not live without? Did I miss your favorite? Let me know in the comments below! 👇

DEV Community: Khatai Huseynzada

What a chess parser taught me about trusting user input

"It's just a string" is the lie

Door 1: length, before anything else

Door 2: parsing is validation, not decoration

Door 3: JSON.parse is not a safe way to read stored data

Door 4: sanitize at the boundary, based on where it's going

The mental model that stuck

I built a Chess Diagram Generator from scratch using React and Raw SVG (0 external chess libraries)

🔥 Roast My Code! (I need your feedback)

🛠️ Want to contribute? (Good First Issues)

7 months building an open-source chess tool. Here's what actually happened.

Why I kept going

The bugs that actually taught me something

What I got wrong

The npm package

Where I'm at

Stop Using console.log(): 5 Hidden Chrome DevTools Superpowers 🚀

1. Convert Network Requests to Code Instantly ("Copy as Fetch") 🌐

2. Visualize Arrays and Objects with console.table() 📊

3. Turn Your Browser into a Live Text Editor (designMode) ✍️

4. Lightning-Fast DOM Access in the Console ($0) ⚡

5. Debug Loops Painlessly with Conditional Breakpoints 🛑

Wrapping Up

2. Visualize Arrays and Objects with `console.table()` 📊

3. Turn Your Browser into a Live Text Editor (`designMode`) ✍️

4. Lightning-Fast DOM Access in the Console (`$0`) ⚡