DEV Community: Ashish Kumar

OPFS: The Browser's Built-in Filesystem Explained

Ashish Kumar — Wed, 29 Apr 2026 00:30:00 +0000

localStorage caps at 5MB. IndexedDB writes a 50MB buffer in ~850ms — slow enough to feel it. The Cache API is effectively read-only. The File System Access API requires user permission prompts every session. None of these were designed for what serious client-side applications actually need: large, fast, random-access binary storage that persists across sessions without permission prompts.

The Origin Private File System (OPFS) fills that gap. It is a real, sandboxed filesystem per origin, invisible to the OS file manager, persistent across sessions, and accessible with a synchronous API from within Workers that makes large sequential I/O genuinely fast.

What this covers: The OPFS API in detail, the synchronous access handle (and why it only works in Workers), streaming network responses directly to OPFS, the performance difference vs IndexedDB, and how SQLite runs in the browser using OPFS as its backing store.

The storage landscape problem

Before OPFS existed, the browser gave you four options for persistent storage, and each one was the wrong tool for at least one important job:

localStorage is synchronous (which feels nice), but the 5–10MB limit is a hard wall. It is also string-only, so storing binary data means base64 encoding which inflates size by ~33% and makes a 5MB limit feel like 3.7MB.

IndexedDB can handle gigabytes in theory, is asynchronous, and supports structured objects and binary blobs. But the API is callback-hell wrapped in a transaction model that wasn't designed for ergonomics. More practically: writing large sequential blobs to IndexedDB is slow. The implementation serializes data through the structured clone algorithm on every write, and for large files you feel that cost. I measured ~400ms to write a 50MB buffer in Chrome on M2 fine once, unbearable repeatedly.

Cache API (Service Worker caches) is designed for HTTP responses and works well for caching network resources. But it is fundamentally read-after-write: you cannot partially update a cached entry or seek to an offset. Building a writable file system on top of it is like building a database on top of a log file possible in theory, miserable in practice.

File System Access API lets you open actual OS files with a picker. That's useful for "open a video from your desktop" flows, but it's not sandboxed the user sees the file in their Downloads folder, file paths can leak, and the permission model requires a user gesture every session. It's the wrong tool for internal app storage.

OPFS is the missing piece: a sandboxed filesystem per origin, invisible to the OS file manager, persistent across sessions, and critically accessible with a synchronous API from within Workers.

What OPFS actually is

The Origin Private File System is a real filesystem exposed to web pages through the StorageManager API. Every origin gets its own isolated root directory. Files you create there are not visible in the OS Finder/Explorer. Other origins cannot access them. Clearing site data removes them.

You access the root with:

const root = await navigator.storage.getDirectory();

That returns a FileSystemDirectoryHandle. From there you navigate a real directory tree:

// Create or open a subdirectory
const cacheDir = await root.getDirectoryHandle('datasets', { create: true });

// Create or open a file
const fileHandle = await cacheDir.getFileHandle('analytics-v3.bin', { create: true });

To write to that file, you create a writable stream:

const writable = await fileHandle.createWritable();
await writable.write(myArrayBuffer);
await writable.close();

To read it back:

const file = await fileHandle.getFile(); // returns a File object
const buffer = await file.arrayBuffer();
// or: const stream = file.stream();
// or: const text = await file.text();

The File object you get from getFile() is the same File type you'd get from an <input type="file">. You can pass it directly to new Response(file), pipe its .stream() into a TransformStream, or just read it as an ArrayBuffer. This composability is one of the things I genuinely like about the API.

The synchronous access handle why it matters

Here is the part that makes OPFS genuinely different from everything else: inside a Web Worker, you can open a file in synchronous mode.

// Inside a Worker
const root = await navigator.storage.getDirectory();
const fileHandle = await root.getFileHandle('dataset.bin', { create: true });

// This is a synchronous handle  only available in Workers
const syncHandle = await fileHandle.createSyncAccessHandle();

// Synchronous read
const buffer = new ArrayBuffer(1024 * 1024);
const bytesRead = syncHandle.read(buffer, { at: 0 });

// Synchronous write
const data = new Uint8Array([1, 2, 3, 4]);
syncHandle.write(data, { at: 0 });

// You must flush and close explicitly
syncHandle.flush();
syncHandle.close();

The createSyncAccessHandle() method is only available in dedicated Workers it deliberately cannot be called on the main thread, because synchronous I/O on the main thread would block rendering. But in a Worker, synchronous access is exactly what you want: no Promise overhead, no microtask queue, just a tight read/write loop that runs at native speed.

The performance difference is meaningful. In my testing, writing a 100MB ArrayBuffer with createSyncAccessHandle took ~90ms. The equivalent IndexedDB write took ~850ms. The gap comes from two places: OPFS bypasses the structured clone algorithm for raw binary data, and the synchronous handle avoids the async event loop overhead that accumulates across thousands of small writes.

Worker + OPFS patterns

The right architecture is: all OPFS work in a Worker, communicate with the main thread via messages.

Here's the pattern I ended up with:

// opfs-worker.js
self.onmessage = async (event) => {
  const { type, payload } = event.data;

  if (type === 'WRITE_FILE') {
    const { path, buffer } = payload;
    const root = await navigator.storage.getDirectory();
    const handle = await root.getFileHandle(path, { create: true });
    const syncHandle = await handle.createSyncAccessHandle();

    syncHandle.truncate(0);
    syncHandle.write(new Uint8Array(buffer), { at: 0 });
    syncHandle.flush();
    syncHandle.close();

    self.postMessage({ type: 'WRITE_DONE', path });
  }

  if (type === 'READ_FILE') {
    const { path } = payload;
    const root = await navigator.storage.getDirectory();
    const handle = await root.getFileHandle(path);
    const file = await handle.getFile();
    const buffer = await file.arrayBuffer();

    // Transfer the buffer (zero-copy)
    self.postMessage({ type: 'READ_DONE', path, buffer }, [buffer]);
  }
};

// main thread
const worker = new Worker('/opfs-worker.js');

worker.postMessage({
  type: 'WRITE_FILE',
  payload: { path: 'analytics-v3.bin', buffer: myArrayBuffer }
}, [myArrayBuffer]); // transfer ownership  zero copy

worker.onmessage = (event) => {
  if (event.data.type === 'READ_DONE') {
    processData(event.data.buffer);
  }
};

The key here is Transferable objects. When you pass [myArrayBuffer] as the second argument to postMessage, ownership transfers to the Worker no copy is made. For a 150MB buffer, this matters. Without transfer, the browser would serialize and copy the data twice (once into the Worker's memory, once back). With transfer, it's a pointer swap essentially free.

Streaming writes from the network

One of the most useful patterns is streaming a network response directly to OPFS, without ever materializing the full response in memory:

// Stream a large file from the network directly to OPFS
async function streamToOPFS(url, filename) {
  const root = await navigator.storage.getDirectory();
  const fileHandle = await root.getFileHandle(filename, { create: true });
  const writable = await fileHandle.createWritable();

  const response = await fetch(url);

  if (!response.body) throw new Error('ReadableStream not supported');

  // Pipe the response body directly to OPFS
  await response.body.pipeTo(writable);
  // writable is automatically closed when pipeTo() resolves
}

createWritable() returns a FileSystemWritableFileStream, which implements the WHATWG WritableStream interface. That means you can pipeTo() any ReadableStream directly into it including response.body. The data flows through without a single full-buffer copy in JavaScript land. For large WASM binaries or video files, this is the right way to download and cache them.

Real use case: caching a 200MB WASM binary

This was essentially what we were doing. We had a data-processing WASM module that was 200MB and updated infrequently. On first load, we streamed it from the CDN into OPFS. On subsequent loads, we checked if the cached version was current (compared an ETag stored in localStorage), and if so, read it straight from OPFS:

async function getWasmModule(url, etag) {
  const root = await navigator.storage.getDirectory();
  const cacheDir = await root.getDirectoryHandle('wasm-cache', { create: true });

  try {
    const storedEtag = localStorage.getItem('wasm-etag');
    if (storedEtag === etag) {
      const handle = await cacheDir.getFileHandle('module.wasm');
      const file = await handle.getFile();
      return WebAssembly.compileStreaming(new Response(file.stream(), {
        headers: { 'Content-Type': 'application/wasm' }
      }));
    }
  } catch {
    // File doesn't exist yet, fall through to fetch
  }

  // Fetch and cache
  const response = await fetch(url);
  const [stream1, stream2] = response.body.tee();

  const handle = await cacheDir.getFileHandle('module.wasm', { create: true });
  const writable = await handle.createWritable();

  // Write to OPFS and compile simultaneously
  const [wasmModule] = await Promise.all([
    WebAssembly.compileStreaming(new Response(stream1, {
      headers: { 'Content-Type': 'application/wasm' }
    })),
    new Response(stream2).arrayBuffer().then(buf => writable.write(buf)).then(() => writable.close())
  ]);

  localStorage.setItem('wasm-etag', etag);
  return wasmModule;
}

The ReadableStream.tee() lets us split one response body into two one piped into WASM compilation, one saved to OPFS. The module compiles and caches in a single network round trip.

OPFS + SQLite: the surprising use case

One of the most interesting production uses of OPFS is as a backing store for SQLite in the browser. The sqlite-wasm project (the official SQLite WASM build) uses the synchronous OPFS access handle to implement POSIX-style file I/O:


const sqlite3 = await sqlite3InitModule({ print: console.log });

// Use OPFS-backed database (runs in a Worker)
const db = new sqlite3.oo1.OpfsDb('/myapp.sqlite3');
db.exec('CREATE TABLE IF NOT EXISTS events (id INTEGER PRIMARY KEY, data TEXT)');
db.exec("INSERT INTO events(data) VALUES('hello')");
const rows = db.exec({ sql: 'SELECT * FROM events', returnValue: 'resultRows' });

This is a full SQLite database, persisted to OPFS, with ACID transactions, SQL queries, and all the features you'd expect running entirely in the browser. The sync handle's random-access read/write is what makes this possible: SQLite needs to be able to seek to arbitrary byte offsets and do partial writes, which is exactly what syncHandle.read(buffer, { at: offset }) provides.

Storage comparison table

	localStorage	IndexedDB	Cache API	OPFS
Size limit	~5MB	Hundreds of MB / GB	Hundreds of MB / GB	Hundreds of MB / GB
API style	Synchronous	Async (promises)	Async (promises)	Async main / Sync in Worker
Binary support	No (base64 only)	Yes (Blob/ArrayBuffer)	Yes (Response body)	Yes (native)
Random access	No	No (seek via cursors)	No	Yes (`{ at: offset }`)
Write speed (100MB)	N/A	~850ms	N/A	~90ms (sync handle)
Streaming writes	No	No	Via fetch	Yes (WritableStream)
Worker access	Yes	Yes	Yes	Yes (sync handle in Worker)
Best for	Small key-value config	Structured app data	HTTP response caching	Large blobs, binary files, SQLite

Quota management

OPFS storage counts toward the origin's storage quota, shared with IndexedDB and the Cache API. The browser manages this as a pool. You can query it:

const estimate = await navigator.storage.estimate();
console.log(`Used: ${estimate.usage} bytes`);
console.log(`Available: ${estimate.quota - estimate.usage} bytes`);

// Breakdown by storage type
console.log(estimate.usageDetails);
// { indexedDB: 1234567, caches: 0, fileSystem: 208000000 }

On Chrome, the quota is typically around 60% of available disk space. On mobile, it can be much smaller, and the browser can evict storage under pressure unless you've called navigator.storage.persist() and the user granted permission.

// Request persistent storage (shows a permission prompt or is auto-granted based on engagement)
const isPersisted = await navigator.storage.persist();
if (!isPersisted) {
  console.warn('Storage may be evicted under disk pressure');
}

For a production app, always check estimate() before writing large blobs and handle the case where quota is insufficient gracefully.

Browser support

Browser	OPFS Available	Sync Access Handle	Notes
Chrome 102+	Yes	Yes (Chrome 108+)	Full support
Firefox 111+	Yes	Yes	Full support
Safari 15.2+	Yes	Yes (Safari 16+)	Full support
Edge 102+	Yes	Yes	Chromium-based
iOS Safari 15.2+	Partial	Yes (16+)	Storage limits tighter
Chrome Android	Yes	Yes	Same as desktop

The main gap to watch is iOS Safari storage limits Apple's browsers on iOS are more aggressive about quota eviction and the persist() permission is harder to get. If you're targeting iOS for large offline datasets, test on actual iOS hardware and check estimate() before assuming you have the space.

Wrapping up

OPFS is not glamorous. It doesn't show up in "top 10 web APIs" listicles. But if you've ever hit the limits of IndexedDB for large binary data, or tried to build an offline-capable app with complex storage needs, it's the API that should have been there all along.

The mental model is simple: it's a real filesystem, sandboxed per origin, with a synchronous API available in Workers that makes large sequential I/O genuinely fast. Pair it with Transferable objects for zero-copy messaging, stream network responses directly into it, and use sqlite-wasm if you need a full relational layer.

The storage landscape went: localStorage → IndexedDB → Cache API → File System Access API → OPFS. Each one fills a different gap. OPFS fills the one that matters most for serious client-side data: fast, large, random-access binary storage that you actually control.

Read the original article on Renderlog.in:
https://renderlog.in/blog/origin-private-file-system-opfs/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

Network Optimization in React SPAs: Prefetching

Ashish Kumar — Tue, 28 Apr 2026 00:30:00 +0000

SPAs bypass the browser's built-in HTTP caching by routing in JavaScript: the page never reloads, so the browser never re-evaluates cache headers on the HTML. Every component instance fetches its own data. Two components on the same page requesting /api/user fire two separate network requests. Navigating back to a route you visited 30 seconds ago triggers a full refetch.

Why this matters: Each useEffect-based fetch introduces a render-then-fetch waterfall. Stacked across multiple nested route components, this compounds to seconds of latency on navigations that could be instant with correct caching.

What this covers: HTTP cache headers and stale-while-revalidate, how React Query implements client-side SWR, request deduplication, avoiding request waterfalls with route loaders, prefetch-on-hover, and Service Worker caching strategies.

The SPA network problem

Server-rendered apps get HTTP caching for free the browser caches the HTML response, and subsequent navigations can be served from the browser cache. SPAs bypass this by routing in JavaScript: the page never reloads, so the browser never re-evaluates cache headers on the HTML. The app controls its own data fetching, and by default, React components have no shared cache every component instance fetches its own data.

The consequences compound:

Waterfall fetches on navigation a route component mounts, kicks off a useEffect, waits for the response, then maybe kicks off more fetches based on the result
No deduplication two components on the same page both requesting /api/user will fire two separate network requests
Cache amnesia navigating back to a page you visited 10 seconds ago triggers a full refetch
Loading states everywhere because you're always waiting for network, even for data you theoretically already have

Fixing this properly requires thinking at multiple levels: HTTP caching, in-memory client-side caching, and request coordination.

HTTP cache headers: the foundation you're probably skipping

Before reaching for a library, it's worth understanding what HTTP caching can do for you. Most React apps I've seen send API responses with Cache-Control: no-cache or no cache headers at all effectively opting out of one of the most powerful performance mechanisms in the web platform.

The Cache-Control header controls how long a response can be cached:

# Cache for 60 seconds, no revalidation needed
Cache-Control: max-age=60

# Cache but always revalidate with If-None-Match before using
Cache-Control: no-cache
ETag: "abc123"

# Serve cached version immediately, revalidate in background
Cache-Control: max-age=60, stale-while-revalidate=300

max-age tells the browser it can use the cached response for N seconds without hitting the network at all. For data that changes infrequently (user settings, feature flags, navigation structure), setting max-age=300 (5 minutes) eliminates unnecessary network round trips on every navigation.

ETag lets the server say "this is version X of this resource." On subsequent requests, the browser sends If-None-Match: "abc123". If the resource hasn't changed, the server responds with 304 Not Modified and no body the browser uses its cached copy. You save bandwidth but still pay the round-trip latency. Useful for data that changes unpredictably.

stale-while-revalidate is the most useful directive for SPA data. It means: serve the cached version immediately (no network wait), but in the background revalidate with the server. If the server has fresh data, update the cache for the next request. The user never sees a loading state they see the old data instantly, and if anything changed, it updates on the next navigation.

The actual HTTP stale-while-revalidate directive requires server-side support. But even if your API doesn't support it, you can implement the same pattern in client-side JavaScript which is exactly what React Query and SWR do.

Stale-while-revalidate in JavaScript: React Query internals

React Query (now TanStack Query) implements the stale-while-revalidate pattern in the browser's memory. Here's the mental model:

On the first request for a query key, fetch from the network and cache the result
On subsequent requests for the same key, return the cached result immediately
If staleTime has elapsed, fire a background revalidation request
When revalidation completes, update the cache and re-render components that are subscribed to this key

// Basic React Query setup
const { data, isLoading, isFetching } = useQuery({
  queryKey: ['user', 'profile'],
  queryFn: () => fetch('/api/user/profile').then(r => r.json()),
  staleTime: 60 * 1000,      // Data is "fresh" for 60 seconds
  gcTime: 5 * 60 * 1000,     // Keep in memory for 5 minutes after last use
});

// isLoading: true only on the very first fetch (no cached data)
// isFetching: true whenever a network request is in flight (including background)

The key distinction is isLoading vs isFetching. isLoading is true only when there's no cached data at all the initial state. isFetching is true during any network activity, including background revalidations. If you show your loading spinner on isFetching instead of isLoading, you'll show a spinner during every background revalidation, which is the bug we started with.

// WRONG: shows spinner during background refetches
if (isFetching) return ;

// RIGHT: only shows spinner when there's genuinely no data to show
if (isLoading) return ;
return ;

Request deduplication

Request deduplication means that if two components both request the same query key simultaneously, only one network request fires. React Query handles this automatically:

// Both of these components can exist on the same page simultaneously.
// React Query fires exactly ONE network request for ['user', 'profile'].

function Header() {
  const { data } = useQuery({ queryKey: ['user', 'profile'], queryFn: fetchProfile });
  return ;
}

function Sidebar() {
  const { data } = useQuery({ queryKey: ['user', 'profile'], queryFn: fetchProfile });
  return ;
}

Under the hood, React Query maintains a query cache keyed by the serialized query key. When the second component calls useQuery with the same key while the first request is still in-flight, it subscribes to the same pending Promise. Both components re-render when the single request resolves.

Without this, a page with 3 components all fetching the user profile would fire 3 API calls on every mount. With React Query, it's always 1. At scale across hundreds of components, dozens of users, millions of navigations this is a meaningful reduction in API server load, not just network performance.

Avoiding request waterfalls in React

The most expensive network pattern in React SPAs is the request waterfall: a component mounts, fetches data, receives the response, then fetches more data based on what it received.

// WATERFALL: this pattern creates a network chain
function UserDashboard() {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState(null);

  useEffect(() => {
    fetchUser().then(u => {
      setUser(u);
      // Can't fetch posts until we have the userId  creates a waterfall
      fetchPostsByUser(u.id).then(setPosts);
    });
  }, []);
}

If fetchUser takes 200ms and fetchPostsByUser takes 150ms, total load time is 350ms. If you parallelize them (when you know the userId ahead of time), it's 200ms. The waterfall cost compounds with every additional sequential fetch.

React Router loaders solve this by moving data fetching outside the component tree:

// React Router v6.4+ loaders

  // These run in parallel  no waterfall
  const [user, posts] = await Promise.all([
    fetchUser(params.userId),
    fetchPostsByUser(params.userId)
  ]);
  return { user, posts };
}

function UserDashboard() {
  const { user, posts } = useLoaderData();
  // Data is already here when the component mounts
  return ;
}

Loaders run as soon as the route transition begins before the component mounts, and in parallel with each other if multiple routes load simultaneously. The component never needs a loading state for the initial data.

Prefetching strategies

Prefetching is fetching data before the user navigates to it so when they do navigate, the data is already in cache.

React Query exposes queryClient.prefetchQuery() for this:

const queryClient = useQueryClient();

// Prefetch on hover  user is probably about to click
function NavLink({ to, queryKey, queryFn, children }) {
  const prefetch = () => {
    queryClient.prefetchQuery({ queryKey, queryFn, staleTime: 10000 });
  };

  return (

  );
}

The trick with hover prefetching is that the human reaction time from hover to click is typically 100–200ms. A fast API response takes 50–150ms. If you kick off the prefetch on hover, the data is often already in cache by the time the navigation happens.

For less predictable navigation, prefetch on requestIdleCallback:

// Prefetch the most likely next routes when the browser is idle
function prefetchLikelyRoutes(queryClient) {
  requestIdleCallback(() => {
    LIKELY_NEXT_ROUTES.forEach(({ queryKey, queryFn }) => {
      queryClient.prefetchQuery({ queryKey, queryFn, staleTime: 30000 });
    });
  }, { timeout: 2000 });
}

Resource hints: preconnect, prefetch, preload

HTML resource hints give the browser signals about what to load before the page needs it:

<!-- Preconnect: establish TCP/TLS with the API domain early -->
<link rel="preconnect" href="https://api.myapp.com" />

<!-- Prefetch: download a resource in the background for future navigations -->
<link rel="prefetch" href="/dashboard" />

<!-- Preload: download a resource needed for THIS page, high priority -->
<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin />

Hint	Priority	When to use
`preconnect`	High	Known API domains you'll fetch from on page load
`dns-prefetch`	Low	Domains you might fetch from (lower cost than preconnect)
`preload`	High	Resources needed for current page (LCP image, critical font, main JS)
`prefetch`	Idle	Resources needed for likely next page (low-priority, uses idle time)
`modulepreload`	Medium	JavaScript modules needed for next route

preconnect is the easiest win. Your API domain requires DNS lookup + TCP handshake + TLS handshake before the first byte that's typically 100–300ms. With <link rel="preconnect">, that work happens while the HTML is being parsed, not when your JavaScript first calls fetch().

Priority Hints

fetchpriority tells the browser how to prioritize resource downloads:

<!-- LCP image: fetch immediately, high priority -->
![](https://renderlog.in/hero.jpg)

<!-- Below-fold image: deprioritize -->
![](https://renderlog.in/footer-decoration.jpg)

// High-priority fetch for critical data
const criticalData = await fetch('/api/critical-config', {
  priority: 'high'
});

// Low-priority fetch for analytics or non-blocking data
fetch('/api/track-view', { priority: 'low' });

The browser has a limited number of simultaneous connections per domain (typically 6 for HTTP/1.1, effectively unlimited for HTTP/2). Without priority hints, it fetches in order of discovery which might mean your LCP image is queued behind a dozen low-priority requests. fetchpriority="high" ensures the browser front-runs it.

Service Workers for network interception

A Service Worker sits between your app and the network and can implement sophisticated caching strategies:

// service-worker.js
const CACHE_NAME = 'api-cache-v1';
const CACHEABLE_APIS = ['/api/user/profile', '/api/feature-flags'];

self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url);

  if (CACHEABLE_APIS.some(path => url.pathname.startsWith(path))) {
    event.respondWith(staleWhileRevalidate(event.request));
  }
});

async function staleWhileRevalidate(request) {
  const cache = await caches.open(CACHE_NAME);
  const cached = await cache.match(request);

  // Always kick off a revalidation in the background
  const networkFetch = fetch(request).then(response => {
    if (response.ok) {
      cache.put(request, response.clone());
    }
    return response;
  });

  // Return cached immediately if available, else wait for network
  return cached || networkFetch;
}

The Service Worker pattern is more powerful than React Query alone for one reason: it works across page loads. React Query's cache lives in memory it's cleared when the user closes the tab. A Service Worker cache persists across navigations and can serve data offline.

Connection-aware fetching

The Network Information API gives you the user's connection type, which lets you adapt what you fetch:

const connection = navigator.connection;

function getImageQuality() {
  if (!connection) return 'high'; // API not supported, assume fast

  if (connection.saveData) return 'low'; // User explicitly wants to save data
  if (connection.effectiveType === '2g') return 'low';
  if (connection.effectiveType === '3g') return 'medium';
  return 'high';
}

// Adaptive image loading
const quality = getImageQuality();
const imageUrl = `/api/image/${id}?quality=${quality}`;

The API is available in Chrome and Android browsers but not Safari. Always check for its existence before using it, and never use it as the only signal fall back to a sensible default.

What the network tab tells you

When diagnosing SPA network performance, I filter the Chrome DevTools Network tab to XHR/Fetch and look for:

Duplicate requests same URL called multiple times in rapid succession (deduplication needed)
Sequential requests requests starting only after previous ones complete (waterfall pattern)
Cache misses on repeat visits Status: 200 on requests you'd expect to be 304 Not Modified (cache headers misconfigured)
Unthrottled polling the same request firing every few seconds even when nothing changed
Stacking spinners multiple loading states visible at once (data needs to be fetched in parallel, not sequentially)

The rule of thumb I use: if you see the same URL more than once in a 10-second window without explicit user action, you have a caching problem.

Putting it together

The layered approach to SPA network performance:

Layer	Mechanism	Wins
HTTP	`Cache-Control`, `ETag`, `stale-while-revalidate`	Eliminates round trips for stable data
Resource hints	`preconnect`, `preload`	Reduces connection and load latency
Client cache	React Query / SWR	Deduplication, stale-while-revalidate, garbage collection
Routing	Route loaders, parallel fetches	Eliminates sequential waterfall fetches
Prefetching	On hover, on idle	Populates cache before navigation
Service Worker	Cache-first / network-first strategies	Persistence across page loads, offline support

Each layer is independent you can add them incrementally. Start with React Query and staleTime: 60000 on your most-fetched queries, add <link rel="preconnect"> for your API domain, and measure. The 800ms spinner on every navigation usually disappears after just the first two steps.

Read the original article on Renderlog.in:
https://renderlog.in/blog/network-optimization-spa-react/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

DOM Performance on Mobile: Lab vs Real Device Reality

Ashish Kumar — Mon, 27 Apr 2026 00:30:00 +0000

Style recalculation on a page with 10,000 DOM nodes takes ~180ms on a budget Android — 10x the entire 16.6ms frame budget. The exact same scroll that is imperceptible on a developer MacBook drops 90% of frames on a Redmi Note 9 or Samsung A-series device.

Why desktop profiling is misleading: The V8 engine on a budget Android runs at 5–10x lower throughput than on a developer laptop. Chrome's 6x CPU throttle preset is still optimistic for real low-end hardware. The only reliable signal is remote debugging on physical budget devices.

What this covers: DOM size and style recalculation benchmarks on real hardware, content-visibility: auto, CSS contain, passive touch event listeners, IntersectionObserver vs scroll events, and the full mobile debugging workflow.

The mobile hardware reality

Before getting into fixes, it's worth internalizing exactly why budget phones are so much slower not as an abstraction, but as a design constraint.

A typical mid-range Android in 2026 (Redmi Note series, Samsung A-series, Motorola G-series) has:

2–4 CPU cores running at 1.5–2.0 GHz, compared to your MacBook's 8–10 cores at 3–4 GHz
3–4GB RAM (often shared with the OS, background apps, and the GPU)), with aggressive memory pressure killing background tabs
No separate GPU memory the integrated GPU (shares RAM bandwidth with the CPU
Thermal throttling: after 2–3 minutes of heavy load, the chip throttles to 60–70% of its peak frequency to avoid overheating
A **V8 JavaScript engine: that's the same version as desktop but running on a fraction of the hardware

The V8 engine on a budget Android is typically 5–10x slower at JS execution than on a developer laptop. Not because the software is different it's the same engine but because the hardware is so much weaker. The JIT compiler has less time budget, inline caches fill differently, and garbage collection pauses are longer in relative terms.

The consequence: performance profiling on your development machine is actively misleading. You will mark tasks as "fast" that are catastrophically slow on real user hardware.

Chrome DevTools CPU throttling isn't enough

Chrome's "6x slowdown" CPU throttle in DevTools is a software throttle: it introduces artificial delays in the main thread scheduling. It doesn't simulate reduced memory bandwidth, it doesn't simulate thermal throttling, and it doesn't simulate the actual V8 JIT behavior on ARM hardware with constrained memory.

It's better than nothing. But I've found that even the 6x throttle is optimistic compared to a Redmi Note 9 or a Realme 8. Real users are often on hardware that would show up as 8–12x slower in practice.

The only reliable signal is remote debugging on real hardware.

# On Android: enable Developer Options, enable USB Debugging
# On your laptop:
chrome://inspect/#devices

Connect your phone, open the app in Chrome on the phone, and it shows up in chrome://inspect. You get the full DevTools Performance panel Timeline, flame charts, frame rate running against the real hardware. I've started keeping a Redmi Note 9 on my desk specifically for this.

DOM size and style recalculation cost

Here's the fundamental problem with large DOM trees that most developers don't feel until they test on mobile: CSS selector matching is O(n) per element per style recalculation, and it scales badly.

When you invalidate styles on a node (by adding a class, changing a property, or causing a reflow), the browser must re-run selector matching for potentially large subtrees. Selectors are matched right-to-left the browser finds all elements that match the rightmost part of the selector, then walks up the tree checking each parent. A selector like .sidebar .nav-item a:hover can be surprisingly expensive if .sidebar contains hundreds of elements.

Chrome's DevTools calls this "Recalculate Style" in the Performance panel. When you see it taking 50ms+ on a frame, you have a DOM size / selector complexity problem.

Some real numbers from my testing (Redmi Note 9, Chrome 122):

DOM node count	Recalc Style time (class toggle)
500 nodes	~4ms
1,500 nodes	~14ms
3,000 nodes	~35ms
6,000 nodes	~90ms
10,000 nodes	~180ms

At 10,000 nodes, a single class toggle on a parent element costs 180ms 10x the entire 16.6ms frame budget. This is directly why our user's phone was "unusable."

The fix is straightforward in principle: fewer nodes. In practice, this means:

Virtualizing long lists (only render what's in the viewport)
Not using deep nesting for layout purposes that could be flattened
Avoiding display: none containers that still exist in the DOM they still participate in style matching
Auditing third-party components that inject dozens of wrapper divs for no structural reason

Mounting discipline: deferring below-fold components

One of the highest-leverage changes on the scroll path is deferring the mounting of below-fold components. If a component isn't visible when the page loads, you don't need it in the DOM immediately.

The naive approach is requestIdleCallback:

// Don't mount everything at once
function BelowFoldSection() {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    const id = requestIdleCallback(() => setMounted(true), { timeout: 3000 });
    return () => cancelIdleCallback(id);
  }, []);

  if (!mounted) return <div style={{ minHeight: '400px' }} />;
  return ;
}

The better approach for scroll-triggered content is IntersectionObserver:

function LazySection({ children, placeholder }) {
  const [visible, setVisible] = useState(false);
  const ref = useRef(null);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => { if (entry.isIntersecting) setVisible(true); },
      { rootMargin: '200px' } // Start loading 200px before it enters viewport
    );
    if (ref.current) observer.observe(ref.current);
    return () => observer.disconnect();
  }, []);

  return <div ref={ref}>{visible ? children : placeholder}</div>;
}

The 200px rootMargin gives you a buffer: components start mounting before the user scrolls to them, so there's no visible loading flash. Measure the actual mount cost of each section in the Performance panel before deciding which ones to defer.

`content-visibility: auto`

CSS content-visibility: auto is a one-liner that tells the browser to skip layout and paint for off-screen content entirely. It's essentially the CSS-native version of the above IntersectionObserver pattern, but implemented at the rendering engine level rather than in JavaScript.

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px; /* Hint for placeholder height */
}

When an element with content-visibility: auto is off-screen, the browser skips its layout and paint entirely. It doesn't remove it from the DOM (the content is still there and accessible), but the browser treats it as if it has visibility: hidden for rendering purposes. When it scrolls into view: the browser renders it on demand.

The contain-intrinsic-size property gives the browser a fallback size to use for layout calculations while the content isn't rendered. Without it, the element collapses to 0 height, which makes scrollbar sizing wrong and can cause layout jumps as content renders.

The limitation: if your sections have genuinely variable heights and you don't know them ahead of time, contain-intrinsic-size requires estimation. Google shipped a auto keyword (contain-intrinsic-size: auto 500px) that remembers the last rendered size, which handles this in most cases.

The performance improvement is real. The Chrome team's case study showed 7x rendering improvement on a long article page. On mobile hardware with 3,000+ nodes in a long-form page, this is one of the highest-ROI CSS changes you can make.

CSS `contain` property

content-visibility uses CSS containment under the hood. Understanding containment directly gives you finer-grained control.

.card {
  contain: layout style paint;
}

The contain property tells the browser that changes inside this element cannot affect anything outside it. There are four containment types:

Containment	What it does
`layout`	Layout inside this element cannot affect outside layout. Enables layout isolation.
`style`	CSS counters and quotes are scoped to this element.
`paint`	Content outside this element's bounds is not painted. Enables paint isolation.
`size`	The element's size is independent of its children. Required for intrinsic-size guarantees.

The practical value of contain: layout paint on card components is that a re-layout inside one card doesn't trigger a full page reflow. On mobile, where reflows are expensive, this is meaningful.

`contain: strict: is shorthand for all four types use it for truly isolated widgets like ads, embeds, or sidebar components that have fixed sizes and no cross-document layout relationships.

Touch scroll performance

iOS has a history with scrolling that explains several CSS properties you'll see in older codebases:

css /* This was required in iOS <13 for momentum scrolling */ .scroll-container { overflow: scroll; -webkit-overflow-scrolling: touch; /* Deprecated but still seen */ }

-webkit-overflow-scrolling: touch was originally required on iOS to get the native momentum scroll behavior inside overflow containers. It's been deprecated since iOS 13 (the browser now handles it automatically), but it still appears in codebases. You can safely remove it today.

What still matters is passive event listeners for touch handlers:

`js
// BAD: blocks scroll until handler returns
element.addEventListener('touchstart', handler);

// GOOD: tells browser the handler won't call preventDefault()
element.addEventListener('touchstart', handler, { passive: true });
`

When a touch event listener is registered without { passive: true }, the browser must wait for your handler to return before it can scroll because your handler might call e.preventDefault() to cancel the scroll. This waiting introduces scroll jank. With { passive: true }, the browser knows it can start scrolling immediately without waiting.

Chrome DevTools will warn you about non-passive scroll listeners in the console:

[Violation] Added non-passive event listener to a scroll-blocking event

This is one of the easiest performance wins on mobile: just add { passive: true } to every touchstart, touchmove, and wheel listener that doesn't need to block the scroll.

Scroll jank: the full picture

Scroll jank sources ranked by how often I see them in real apps:

Source	Cause	Fix
Non-passive listeners	Browser waits for JS before scrolling	`{ passive: true }`
Layout reads during scroll	`getBoundingClientRect()` / `offsetTop` in scroll handler	Batch reads, use IntersectionObserver
Heavy onscroll handlers	DOM manipulation, state updates every pixel	Throttle with `requestAnimationFrame`
Large DOM	Style recalc dominates frame time	Virtualize lists, reduce node count
Compositor-layer overflow	Too many `will-change` / `transform: translateZ(0)`	Audit GPU memory usage

The requestAnimationFrame pattern for scroll handlers is worth knowing:

`js
let lastScroll = 0;
let ticking = false;

window.addEventListener('scroll', () => {
lastScroll = window.scrollY;

if (!ticking) {
requestAnimationFrame(() => {
updateUI(lastScroll);
ticking = false;
});
ticking = true;
}
}, { passive: true });
`

This ensures your scroll handler runs at most once per frame, aligned with the browser's render schedule, rather than potentially dozens of times between frames.

IntersectionObserver vs scroll events

IntersectionObserver is off the main thread. The browser handles the intersection calculations in a separate process and delivers callbacks to your JavaScript only when intersection ratios change. This means it doesn't fire dozens of times per scroll only when something actually enters or exits the viewport.

`js
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
// This callback is batched and off-main-thread for intersection math
entry.target.classList.toggle('visible', entry.isIntersecting);
});
}, { threshold: 0.1 });

document.querySelectorAll('.animate-on-scroll').forEach(el => observer.observe(el));
`

Compare this to the scroll event approach that was common five years ago:

js // Don't do this on mobile window.addEventListener('scroll', () => { document.querySelectorAll('.animate-on-scroll').forEach(el => { const rect = el.getBoundingClientRect(); // Forces layout! if (rect.top < window.innerHeight) { el.classList.add('visible'); } }); });

The scroll version runs on the main thread, calls getBoundingClientRect() on every element (which forces a layout flush), and executes potentially hundreds of times per second. On a Redmi Note 9, this will stutter.

Input latency: the 300ms tap delay

Until around 2017, mobile browsers introduced a 300ms delay before firing click events from taps. The reason: the browser needed to wait to see if the tap was the first tap of a double-tap zoom gesture. This is now mostly resolved, but the fix is worth knowing:

css /* Eliminates 300ms tap delay on elements */ .button { touch-action: manipulation; }

touch-action: manipulation tells the browser this element supports tap and pan but not double-tap-to-zoom, so the 300ms wait isn't needed. Modern browsers (Chrome 55+, Safari 13+) have removed the delay globally for pages with a <meta name="viewport" content="width=device-width"> tag, but touch-action: manipulation is belt-and-suspenders for interactive elements on older devices.

Images on mobile

Image rendering is a surprising source of main thread cost on mobile:

`html

The three attributes that matter for mobile performance:

loading="lazy": defers fetching images outside the viewport. On a page with 20 images, this can save 5–10MB of initial load on mobile.
decoding="async": tells the browser to decode the image off the main thread. Without this, large image decodes happen synchronously and can spike frame times.
sizes: tells the browser which image to download based on the viewport width. Without accurate sizes, the browser guesses wrong and often downloads the full-size image on a phone.

Always specify explicit width and height on images. Without them, the browser can't reserve space for the image before it loads, causing Cumulative Layout Shift which is even more jarring on mobile where reflows are slower.

Putting it together

The mobile performance debugging workflow I follow now:

Profile on real hardware don't trust desktop throttle
Check DOM node count anything over 1,500 nodes in the initial render deserves scrutiny
Add content-visibility: auto to long-page sections
Add { passive: true } to all scroll/touch listeners
Replace scroll listeners with IntersectionObserver where possible
Check for getBoundingClientRect() in scroll handlers (it forces layout)
Virtualize any list over 100 items use react-virtuoso or @tanstack/virtual
Set explicit image dimensions and add loading="lazy" + decoding="async"

Budget mobile devices are not edge cases: they're often the majority of your users' hardware outside of North America and Western Europe. Building with that constraint in mind from the start is dramatically cheaper than retrofitting it after your analytics start showing high bounce rates on Android.

Read the original article on Renderlog.in:
https://renderlog.in/blog/mobile-web-dom-performance/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

React Re-rendering: When and Why Component Trees Update

Ashish Kumar — Sun, 26 Apr 2026 00:30:00 +0000

Related: Long Tasks and Main Thread Blocking heavy React renders are one of the most common sources of Long Tasks.

React's default re-render behavior is intentionally conservative: when a parent re-renders, all children re-render too. This is correct by default — React prioritizes correctness over performance, and render-phase work (function calls, hook execution) is cheap enough that unnecessary re-renders are often harmless. But "often harmless" is not "always harmless."

What this covers: The exact four triggers that cause a component to re-render, how reconciliation and the fiber tree work, why referential equality matters for memoization, the context performance trap, and how to read the React DevTools Profiler to find the root cause of unexpected re-renders.

Render phase vs commit phase

React's work of "updating the UI" is split into two fundamentally different phases. Confusing them is the root of a lot of performance misconceptions.

The render phase

The render phase is when React calls your component functions and figures out what the UI should look like. When you call setState, React schedules a render. During the render phase, React:

Calls the component function (your function component body executes).
Calls all the hooks in order (useState, useEffect, useMemo, etc.).
Gets the returned JSX.
Does this recursively for any child components that also need updating.
Diffs the new output against the previous output (reconciliation).

Critical insight: the render phase is pure work: React is just computing what the UI should be. **It doesn't touch the DOM yet.* Your component function can be called and produce output that React then decides to discard (this is what StrictMode's double-render exploits see below).

The commit phase

The commit phase is when React actually applies changes to the DOM. It has three sub-phases:

Before mutation: fires getSnapshotBeforeUpdate lifecycle and captures current DOM state.
Mutation: applies DOM insertions, updates, and deletions. This is the only time React directly touches the DOM.
Layout: fires useLayoutEffect and componentDidMount/componentDidUpdate synchronously. This is why useLayoutEffect can measure DOM layout the DOM is updated but the browser hasn't painted yet.
After the commit, useEffect callbacks are scheduled for after the browser has painted.

Understanding this split matters because: render phase work is cheap to do multiple times (it's just function calls and object comparisons). Commit phase work touches the DOM and can trigger browser reflow. React is clever about doing as little DOM work as possible.

Reconciliation and the fiber tree

React doesn't just compare new JSX against a flat list of DOM elements. It maintains an internal data structure called the fiber tree a graph of objects representing every component instance in your app, including their state, hooks, and pending work.

Each fiber corresponds to one component instance. When a state update is triggered, React creates an alternative "work in progress" fiber tree and starts reconciling it against the current tree. This is the reconciliation algorithm.

What reconciliation does:

Compares new JSX element type against the existing fiber's type.
If the type changed (e.g., <Button> became <a>), React unmounts the old component tree and mounts a fresh one.
If the type is the same, React updates the existing fiber with new props, runs hooks again, and recurses into children.
For lists, it uses keys to match new elements to existing fibers.

The key performance insight: reconciliation is proportional to the size of the fiber tree that gets re-rendered. If you trigger a re-render high in the tree, React walks down through all descendants. This is why the settings checkbox caused 47 re-renders the useState was placed in a component that was the parent of almost everything.

What triggers a re-render

There are exactly four causes of a React component re-rendering:

Trigger	Description
setState call	Calling the setter from `useState` or `useReducer` dispatch
Props change	Parent re-renders and passes new prop values (by reference)
Context value changes	Any consumer of a context re-renders when the context value changes
Parent re-renders	A component re-renders when its parent re-renders, even if props didn't change

The fourth one surprises people the most. In React's default behavior, if a parent re-renders, all children re-render too regardless of whether their props changed. This is the default: without memoization, the component tree re-renders in a cascade from the component that triggered the state change, downward.

This is actually a deliberate design choice. React assumes that re-rendering is cheap (it's just function calls) and that computing whether to skip a render is sometimes more expensive than just doing the render. The defaults are optimized for correctness, not maximum performance.

Re-renders don't mean DOM updates

This is a crucial clarification that trips up a lot of performance investigations.

When 47 components re-render, React calls 47 component functions and gets back 47 JSX trees. Then it diffs those against the previous output. If the output is identical, React makes zero DOM changes for that component. No DOM mutations, no browser reflow, nothing.

So "47 components re-rendered" in React DevTools means "47 component functions were called, not "47 DOM nodes were updated." The actual DOM impact depends on how many of those components produced different output.

This distinction matters because: pure render cost (function calls, hook execution) is usually cheap. DOM mutation cost is what triggers browser layout and paint. If your 47 re-rendering components all produce the same output as before, you might have wasted 2ms of JavaScript time, but you've caused zero additional browser rendering work.

That said, 47 function calls isn't free: if any of those functions do expensive computations inline (without useMemo), or if React itself has to run through complex reconciliation logic, you'll feel it.

Why referential equality matters

This is where function components differ fundamentally from the mental model of "props changed = new values." React uses referential equality (===) to compare props and determine if a memoized component should skip its render.

function Parent() {
  const [count, setCount] = useState(0);

  // ⚠️ New object reference created on every render
  const config = { theme: 'dark', size: 'medium' };

  // ⚠️ New function reference created on every render
  const handleClick = () => setCount(c => c + 1);

  return (
    <>


    </>
  );
}

Every time Parent re-renders, config and handleClick are brand new objects. They're deeply equal to the previous values (same shape, same content) but config === previousConfig is false because they're different object references.

If Settings is wrapped in React.memo, it will still re-render because its config prop is a new reference, even though nothing meaningfully changed.

// useMemo stabilizes the reference between renders
const config = useMemo(() => ({ theme: 'dark', size: 'medium' }), []);

// useCallback stabilizes function references
const handleClick = useCallback(() => setCount(c => c + 1), []);

useMemo and useCallback are not about avoiding "expensive computations: they're primarily about referential stability. Their main job is to prevent downstream re-renders caused by new object/function references.

The context performance problem

Context is often described as a solution for "prop drilling: passing data through many levels of components. It is that. It's also a performance footgun if you're not careful about what you put in it.

Context is a broadcast. When the context value changes, every component that consumes that context re-renders, regardless of whether the specific piece of data it reads changed.

// ⚠️ This context re-renders ALL consumers when ANYTHING in the object changes
const AppContext = createContext({
  user: null,
  theme: 'light',
  notifications: [],
  sidebarOpen: false,
});

function App() {
  const [sidebarOpen, setSidebarOpen] = useState(false);

  // New object reference when sidebarOpen changes
  // → Every context consumer re-renders, including deep UI components that only care about `user`
  const value = { user, theme, notifications, sidebarOpen };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

Toggling the sidebar causes every consumer of AppContext to re-render, including components that only ever read user. The fix is to split context by update frequency:

// Stable values that rarely change
const UserContext = createContext(null);
// Dynamic values that change often
const UIStateContext = createContext({ sidebarOpen: false });

// Now sidebar state changes only affect UIStateContext consumers

A useful mental model: each context should have one reason to change. If your context value object contains both stable auth data and frequently-changing UI state, you'll cause unnecessary re-renders across the entire consumer tree.

Keys in lists: what they actually do

Keys serve a specific mechanical purpose during reconciliation. React uses keys to match new list elements to existing fibers when the list changes. Without keys (or with incorrect keys), React falls back to matching by position.

// Without keys  React matches by index
// Adding an item to the beginning: React thinks EVERY item changed
{items.map((item, index) => (

))}

// With stable IDs: React correctly identifies which item was added
{items.map(item => (

))}

When you use key={index} and prepend an item to the list, React sees:

Position 0: had {id: 1}, now has {id: 0} → update this fiber
Position 1: had {id: 2}, now has {id: 1} → update this fiber
etc.

Every fiber gets updated because positions changed, even though only one item was added. With stable IDs, React sees that existing fibers just shifted position and correctly reconciles with minimal work.

The random-key anti-pattern is even worse:

// ⚠️ Generates a new key on every render  destroys all reconciliation benefits
{items.map(item => (

))}

With random keys, every render unmounts all existing Card components and mounts fresh ones. You lose all component state, all DOM node reuse, and get maximum mount/unmount work on every render.

React 18 automatic batching

Before React 18, state updates inside setTimeout, Promise.then, or native event handlers were processed individually: one setState = one re-render.

// React 17: 2 renders
setTimeout(() => {
  setCount(c => c + 1); // Render 1
  setLoading(false);    // Render 2
}, 1000);

// React 18: 1 render (automatic batching)
setTimeout(() => {
  setCount(c => c + 1); // Batched
  setLoading(false);    // Batched → single render
}, 1000);

React 18's automatic batching extends the existing batching behavior (which previously only worked in React event handlers) to all asynchronous contexts. This is a free performance improvement that many apps benefit from immediately after upgrading.

The cases where this matters most: fetch callbacks that update multiple state values, async event handlers that set loading + data states together, and any code that does multiple setState calls in a row in async code.

If you need to explicitly opt out of batching (rare), flushSync from react-dom forces synchronous processing:


// Forces immediate render after each setState
flushSync(() => setCount(1));
flushSync(() => setLoading(false));

StrictMode's double-render in development

If you're using React.StrictMode (you should be in development), your component functions are called twice during the render phase in development mode. This is intentional and a source of confusion for developers who see their console.log appearing twice.

What StrictMode is doing: it deliberately calls your component function twice to check that the function is pure that calling it multiple times with the same inputs produces the same output. If your component has side effects in the render phase (network requests, direct DOM mutations, setting external variables), the double-render will expose them because those effects will fire twice.

function BadComponent() {
  // ⚠️ Side effect in render  this fires twice in StrictMode development
  someGlobalCounter++;

  return <div>{someGlobalCounter}</div>;
}

The double-render only happens in development mode. Production builds render once. If something works in development but breaks in production differently, StrictMode's double-render is not the cause but the bugs it exposes in development might surface as subtle issues in production.

Reading the React Profiler

The React DevTools Profiler is the right tool for understanding re-renders. Open DevTools → Components → Profiler. Hit Record, do the interaction that feels slow, stop recording.

The flame chart shows every component that rendered, how long it took, and crucially why it rendered:

Props changed one or more props have a different reference than the previous render.
State changed a useState or useReducer hook in this component changed.
Context changed a context this component subscribes to changed.
Parent re-rendered no local reason, but the parent rendered so this did too.
Hooks changed a hook produced a different value than before.

The "why did this render?" information is invaluable for diagnosing unnecessary re-renders. When you see "parent re-rendered" for a component that shouldn't care about its parent's state change, that's the target for React.memo. When you see "props changed" for a memoized component that's receiving an object prop, that's the target for useMemo.

Profiler "Why"	Likely fix
"Parent rendered" on a pure display component	Wrap with `React.memo`
"Props changed" on a memoized component	Stabilize prop reference with `useMemo`/`useCallback`
"Context changed" but component only reads one field	Split context by update frequency
"State changed" unexpected	Check if the state is co-located at the right level

The Profiler also shows total render duration per component. If a single component consistently takes 15ms+ to render, that's a component-level optimization opportunity either memoizing expensive calculations inside it or splitting it into smaller pieces.

Read the original article on Renderlog.in:
https://renderlog.in/blog/react-rerendering-when-trees-update/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

OCR in the Browser: How Tesseract.js Makes PDF Text Extraction Free

Ashish Kumar — Sat, 25 Apr 2026 13:49:28 +0000

You've got a 200-page PDF that someone scanned years ago. It's just images of pages — Cmd-F finds nothing. You need to extract the text, search through it, maybe paste a paragraph into a doc.

Five years ago, this meant a cloud OCR API at $1.50 per 1,000 pages, plus uploading your potentially-sensitive PDF to a third-party service. Now it means dropping the file into a tab and waiting two minutes. The thing that made the difference is Tesseract.js — and understanding what it does, where it shines, and where it falls short is worth knowing whether you're building a tool or just trying to get text out of a scan.

This post walks through how browser-based OCR actually works, what to expect from the open-source state of the art, and the engineering decisions that go into shipping it well.

What OCR is, briefly

Optical character recognition takes an image of text and produces actual text characters. Modern OCR engines do this in two stages:

Layout analysis — figure out where the text regions are on the page, in what order they should be read, and where lines and words break.
Character recognition — for each detected word, classify the visual pattern as one of the characters it could be.

Step 2 used to use rule-based image processing (look at the shape, match against templates). Modern engines including Tesseract use neural networks (LSTMs, mostly) trained on huge corpora of text in different fonts and conditions.

The accuracy of a modern OCR engine on clean printed text is 95–99%. On handwriting, multi-column layouts, tables, or low-quality scans, it drops fast. We'll come back to that.

Tesseract: 30 years of OCR, now in your browser

Tesseract is the open-source OCR engine that's been around since 1985. HP wrote it, then it sat unused for a decade, then Google rescued it in 2005, rewrote the engine in 2018 to use LSTMs, and kept improving it. It supports 100+ languages, runs as a command-line tool, and is the engine behind a huge fraction of OCR products you've used.

Tesseract.js is Tesseract compiled to WebAssembly. Same accuracy as the desktop version, runs in any modern browser, no server required. The whole thing is about 8MB compressed (engine + a single language pack), loads on demand, and processes pages at maybe 1–3 seconds each on a typical laptop.

The basic usage is comically simple:

import Tesseract from 'tesseract.js'

const { data: { text } } = await Tesseract.recognize(
  imageOrCanvasOrUrl,
  'eng',
  { logger: m => console.log(m) }
)

console.log(text)

That's it. Pass an image, get back text. The logger is useful because OCR isn't instant — typical pages take a few seconds, and you want a progress bar.

The PDF-to-text pipeline

Tesseract operates on images, not PDFs. So the full pipeline for "OCR a scanned PDF" is:

Open the PDF (use pdf.js)
Render each page to a canvas
Pass the canvas to Tesseract.js
Concatenate the results

The skeleton looks like:

import * as pdfjs from 'pdfjs-dist'
import Tesseract from 'tesseract.js'

async function ocrPdf(file) {
  const buffer = await file.arrayBuffer()
  const pdf = await pdfjs.getDocument(buffer).promise
  const pages = []

  for (let i = 1; i <= pdf.numPages; i++) {
    const page = await pdf.getPage(i)
    const viewport = page.getViewport({ scale: 2 })  // 2x for OCR accuracy
    const canvas = document.createElement('canvas')
    canvas.width = viewport.width
    canvas.height = viewport.height
    await page.render({ canvasContext: canvas.getContext('2d'), viewport }).promise

    const { data: { text } } = await Tesseract.recognize(canvas, 'eng')
    pages.push(text)
  }

  return pages.join('\n\n')
}

A few details that matter:

Render at 2× or 3× scale. OCR accuracy correlates strongly with resolution. The native PDF DPI (72 or 96) is usually too low; bumping to 2× makes a noticeable difference.
Process pages sequentially. Tesseract.js can run multiple workers in parallel, but each worker loads ~8MB of language data, so on memory-constrained devices, sequential is safer.
Show progress. OCR is slow. A 50-page document at 2 seconds/page is 100 seconds — without a progress indicator, users think the page froze.

Web Workers for the UI

If you call Tesseract.recognize directly on the main thread, the page becomes janky during processing. Tesseract.js comes with built-in Worker support — every recognize call runs in a worker by default, but you can also pre-spin workers and reuse them:

const worker = await Tesseract.createWorker('eng')
for (const canvas of canvases) {
  const { data: { text } } = await worker.recognize(canvas)
  // ...
}
await worker.terminate()

Reusing one worker for multiple pages avoids repeated language-data loading. For batches, this is 3–5× faster than the simple form above.

Language packs

Tesseract supports 100+ languages, but each language is a separate trained data file (5–25MB compressed). You don't bundle them — you download on demand:

const worker = await Tesseract.createWorker(['eng', 'spa'])  // English + Spanish

For a multilingual OCR app, the data-loading strategy matters. Don't ship all 100 language packs in your bundle; let users select languages and lazy-load.

A few practical notes:

English is by far the best-tuned. CJK languages (Chinese, Japanese, Korean) work but are slower and slightly less accurate.
Mixed-language documents are tricky. Tesseract supports passing multiple languages, but it tries to apply all of them to every word — this is slower and sometimes less accurate than running it in single-language mode.
Math and code are recognized poorly. OCR engines were trained on natural-language text. Variable names, equations, and code samples often come out scrambled.

Where OCR falls down

Even on clean printed text, you'll hit cases that break:

Low-resolution scans. Anything below 200 DPI gets unreliable. Below 150 DPI, accuracy drops to 70–80%. If your input is a phone photo of a printed page taken in dim light, OCR will struggle.

Multi-column layouts. Tesseract has a layout analyzer, but it sometimes reads across columns instead of down them, producing scrambled output. Newspapers and academic papers are the classic problem cases.

Tables. Tesseract can extract the text from a table, but it loses the structure. You get a flat stream of cell contents in some order. For real tabular data extraction you need a different tool entirely (or a model fine-tuned on table layouts).

Handwriting. Out of scope for Tesseract. Use a model trained for handwriting (Google Cloud Vision, AWS Textract, or specialized libraries). The accuracy gap is enormous.

Low-contrast or skewed pages. Pre-processing helps a lot. Convert to grayscale, increase contrast, deskew. There are JavaScript libraries (opencv.js, cv-tools) that do these transformations in the browser before OCR.

Forms and structured documents. OCR gives you text. It doesn't tell you "this string is the patient's date of birth and this one is the diagnosis." For structured extraction, you need OCR + a separate parsing step (regex, NER models, or templated extraction).

Cloud OCR vs Tesseract.js — when to pick which

Cloud OCR services (Google Cloud Vision, AWS Textract, Azure Computer Vision) are still better than Tesseract on hard cases. They handle handwriting, complex tables, multilingual documents, and edge cases that Tesseract struggles with. They're trained on far more data.

But Tesseract.js wins on three axes:

Privacy — files never leave the browser
Cost — free, no per-page pricing, no API keys
Simplicity — no signup, no auth, no rate limits

The decision rule: for printed-text OCR where you control the inputs (PDFs, screenshots, document scans), Tesseract.js is good enough most of the time. For high-stakes accuracy on edge-case inputs (handwritten forms, mixed handwriting/print, low-quality phone photos of receipts), use a cloud API.

A practical caveat: PDFs that already have text

A surprising fraction of "scanned" PDFs actually have text in them — they were scanned, then put through an OCR pass at the printer or by another tool, and the text is embedded but invisible because the visual layer is the scan. Before running expensive OCR, check:

const page = await pdf.getPage(1)
const textContent = await page.getTextContent()
if (textContent.items.length > 0) {
  // PDF already has text — skip OCR
}

Saves a lot of CPU when the work is already done.

Where to try OCR right now

For a one-off (you have a scanned PDF, you need the text, you don't want to write code), imagetools.renderlog.in and pdftools.renderlog.in both run Tesseract.js client-side. The PDF tool's OCR feature handles the pdf.js → canvas → Tesseract pipeline described above. Drop a PDF in, get text out, file never leaves the browser.

For the actual implementation in your own app, the Tesseract.js GitHub repo is well-documented and the API hasn't changed much in years.

TL;DR

Tesseract.js puts a battle-tested OCR engine in any modern browser at no per-page cost.
The pipeline for OCRing a PDF is: pdf.js renders pages to canvases → Tesseract.js recognizes each canvas → concatenate the text.
Render at 2–3× scale for accuracy. Use Web Workers (built in) to keep the UI responsive.
Pre-check if PDFs already have a text layer before running OCR; many do.
Tesseract is excellent on clean printed text, weak on handwriting, tables, and very low-quality inputs.
For privacy-sensitive documents (medical, legal, contracts), client-side OCR removes the cloud-API trust problem entirely.

Browser-based OCR went from "tech demo" to "ship this in production" in about three years. If you're still uploading scans to a paid API for printed-text extraction, it's worth a re-evaluation.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

Why Client-Side PDF Tools Beat Server Uploads (Privacy, Speed, and Cost)

Ashish Kumar — Sat, 25 Apr 2026 13:48:46 +0000

You need to compress a PDF. You search "compress PDF online", land on a popular site, drag your file in, wait, download the result. Easy.

Now let me ask: what was in that file? A passport scan? A signed contract? Your tax return? A medical report? An NDA from your employer?

You uploaded it to a server. Their server, probably backed up, probably logged, probably handled by a third party. The terms of service almost certainly include something about "we may use your files to improve our service." Even if they delete it after an hour — and you're trusting them to — there's a window where it sat in cleartext on a machine you don't control.

This isn't paranoid. This is what most "free PDF tools" actually do. And it's no longer necessary. Modern browsers can do almost everything those tools do, locally, in your tab, without uploading anything. This post is about why that's a meaningful shift, what made it possible, and what the trade-offs actually are.

How we ended up uploading PDFs to servers

Server-side became the default in the 2010s for a good reason: PDF parsing in JavaScript was awful. The format is decades-old, full of legacy quirks, supports embedded fonts and color profiles and JavaScript and form fields and digital signatures. Implementing even a slice of that in browser JavaScript meant slow, buggy code that worked on simple PDFs and crashed on complex ones.

So PDF tool sites used the obvious workaround: spin up a backend in Python or Java, run a battle-tested library like pdftk, Ghostscript, or iText, and let the browser just upload and download. It worked. Users didn't know — or didn't think about — what their files went through on the way there and back.

Two things changed.

What changed: pdf.js and WebAssembly

pdf.js is the PDF rendering library Mozilla built for Firefox in 2011. It's the engine that displays PDFs natively in the browser without a plugin. Over the years it grew capabilities beyond rendering — extracting text, manipulating pages, handling annotations. It's not perfect, but it's solid for 90% of real PDFs.

WebAssembly changed the second half. Wasm lets you compile high-performance C, C++, and Rust code to a binary format that runs in the browser at near-native speed. Suddenly the same Ghostscript or MuPDF that powered server-side tools could run inside the user's browser. Compression, OCR, format conversion — all the heavy work that used to require a Python service became a Wasm module loaded over HTTP.

By 2022, the toolchain was ready: pdf.js for parsing, Wasm-compiled imaging libraries for compression and conversion, modern browser APIs (Web Workers, OffscreenCanvas) for keeping the UI responsive. A modern browser running on a modern laptop can compress a 50MB PDF faster than a free-tier server can.

The privacy angle

This is the part that matters most to most users.

When you upload a PDF to a server-side tool:

The file traverses your network in plaintext (well, TLS, but it leaves your machine encrypted-in-transit, decrypted-at-rest)
It sits on a third-party machine for some window of time
It may be backed up, cached at a CDN, logged, or analyzed
The provider's privacy policy probably says they delete it after some time, but you have no way to verify
A breach of that provider exposes every file uploaded that day

When you process the same file in a client-side tool:

The file never leaves your browser
No server has a copy, even temporarily
A breach of the tool provider doesn't expose your files
You can use it offline (after the JavaScript loads once)
You can use it with files you legally aren't allowed to upload elsewhere (NDAs, classified-by-contract material, customer PII)

For most personal use, this is "nice to have." For lawyers, medical professionals, government workers, or anyone subject to compliance regimes (HIPAA, GDPR, SOC 2), this is the difference between a tool you can use and one you can't.

The speed angle

Counterintuitively, client-side is often faster than server-side for everyday workflows. The reason: upload time.

A 20MB PDF over a typical home internet upload (10–50 Mbps) takes 4–20 seconds just to reach the server. Then it processes. Then it downloads back. Round-trip on a typical residential connection: 15–45 seconds for processing that takes 2 seconds on the server itself.

A client-side tool skips the round-trip entirely. The same 20MB PDF compresses in 5–10 seconds total, all CPU time, no network. On large files the client-side approach can be 5× faster end-to-end despite using slower hardware.

The exception is genuinely heavy work — OCR on a 500-page scan, batch processing 100 PDFs at once, conversion to obscure formats. There the server's beefier CPU and shared GPUs win. For the 95% of PDF tasks that are merge, split, compress, and basic conversion, the client wins.

The cost angle (for tool builders)

This one's for the developer in you, not the user.

A server-side PDF tool pays per request. Even at $0.0001 per processed file, a tool that handles 100,000 PDFs/day costs $300/month in compute alone. Add bandwidth, storage, and the engineering time to keep the pipeline running. Most "free" PDF tools cover this cost with ads, upsells to premium tiers, or selling user data. None of those align the tool's incentives with yours.

A client-side tool pays for the JavaScript bundle once, hosts static files on a CDN, and serves unlimited users at near-zero marginal cost. Your CPU does the work the server used to. The economics flip from "monetize per user" to "build it once, serve it forever."

This is why client-side tools tend to be free without ads. They cost nothing to run, so they have no pressure to monetize aggressively.

The trade-offs (because there always are some)

Client-side PDF processing isn't a strict upgrade. The honest list:

File size limits. Browser memory is finite. A 500MB PDF that runs fine on a server may crash a tab on a 4GB laptop. Tools usually cap at 100–200MB. If you're regularly working with multi-hundred-MB PDFs, server-side has more headroom.

CPU intensity. Heavy operations spin up the user's CPU. Mobile devices feel it. A 5-minute OCR pass on a 200-page scanned document drains battery and warms up the device.

Browser compatibility. Some operations require modern browser APIs. Old browsers (IE11, Safari before 14, in-app webviews) may not support all features. Modern client-side tools just refuse to load on these — usually fine, occasionally a problem in corporate environments.

Initial load. The Wasm bundle and pdf.js together are 1–3MB of JavaScript. That's a one-time cost (cached after the first visit), but the first load is slower than a thin server-side tool's HTML page.

Genuinely complex documents. Encrypted PDFs with weird DRM, very old PDF/A archival files, ones with embedded JavaScript that interacts with form data — these still trip up client-side libraries more than mature server-side ones. For most real PDFs, it doesn't matter. For some workflows, it does.

How to tell if a "free PDF tool" is actually client-side

Before you upload anything sensitive, do one of these checks:

1. Disconnect from the internet and try to use it. Real client-side tools work offline (after the page has loaded once). Server-side tools fail with a network error.

2. Open browser dev tools, go to the Network tab, and watch what happens when you submit a file. A client-side tool shows zero meaningful network traffic — maybe an analytics ping, no file upload. A server-side tool shows a several-megabyte POST.

3. Read the privacy policy. Server-side tools have to mention file storage, retention, and processing. Client-side tools tend to say "your files never leave your device" and can — that claim is verifiable, not marketing fluff.

4. Check for HTTPS only, no fancy infrastructure. Client-side tools are usually static-hosted (Vercel, Netlify, Cloudflare Pages). The whole site is HTML + JS + Wasm, no backend.

What's possible client-side now

To give a sense of the current state — these are all things modern browsers handle locally without uploading:

Merge, split, and reorder pages
Compress to a target file size (handy for email attachment limits)
Convert PDF to Word or images
OCR scanned PDFs into searchable text
Sign PDFs with a drawn or typed signature
Unlock password-protected PDFs (when you know the password)
Image conversions: HEIC → JPG, WebP → PNG, etc.

pdftools.renderlog.in is one example built this way — everything client-side, no server-side processing of user files, works offline after the first load. It's the kind of tool that would have been impossible in 2015, viable but slow in 2020, and is just normal now.

TL;DR

Server-side PDF tools were a workaround for slow JavaScript that's no longer needed.
Modern browsers + pdf.js + WebAssembly handle 95% of real PDF tasks locally, often faster than upload-process-download workflows.
The privacy implications are real: files you process locally don't end up on someone else's servers.
Cost economics flip from per-user pricing to free static hosting, which removes the pressure to monetize through ads or data.
Trade-offs: file-size limits, CPU intensity on mobile, slightly larger initial bundle.
To tell if a "free" PDF tool is actually client-side: try it offline, watch the Network tab, read the privacy policy.

The next time a PDF tool asks for your file, ask where it's going. With the current state of web tech, the answer should be "nowhere." Anything else is a choice the tool builder made — usually for reasons that don't benefit you.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

A Developer's Guide to Image Formats: JPG, PNG, WebP, AVIF, and HEIC

Ashish Kumar — Sat, 25 Apr 2026 13:48:04 +0000

You're checking in 200 product photos. Should they be JPG? PNG? WebP? AVIF? Whatever the designer dragged in?

This is the question every developer ducks until performance reviews force the conversation. The honest answer is "it depends" — but the dependencies are concrete and learnable, and once you know them you stop wasting bandwidth on the wrong format.

This is a practical guide to the five formats you'll actually touch (JPG, PNG, WebP, AVIF, HEIC), plus a quick note on SVG and GIF. File sizes, when each wins, browser support, the conversion gotchas.

The decision tree

Before the deep dive, here's the rough mental model:

You have...	Use...
A photograph (smooth gradients, lots of color)	JPG, or WebP/AVIF if you can serve them
A screenshot, diagram, logo, or any image with hard edges	PNG, or WebP/AVIF
Something that needs transparency	PNG, or WebP/AVIF
An image that needs to scale to any size (icons, logos)	SVG
A short looping animation	WebP, MP4, or GIF as last resort
A photo from an iPhone	HEIC arriving, JPG/WebP serving

That table covers 90% of cases. The other 10% is in the details.

JPG (JPEG) — the workhorse

Released 1992. Lossy compression tuned for photographs. Discards information humans don't notice — fine color variation in skies, tiny details in busy areas — and keeps file sizes small.

Strengths: universal support, excellent compression for photos, predictable behavior.

Weaknesses: lossy (re-saving degrades quality), no transparency, terrible for text and hard edges (compression artifacts make text look fuzzy).

Practical compression: for photos served on the web, quality 75–85 is the sweet spot. Below 70 starts looking obviously compressed; above 90 wastes bytes for invisible quality. Most image tools default to quality 90 — too high.

Gotcha: don't open a JPG, edit it, and re-save it as JPG repeatedly. Each save is another lossy compression pass; after five or six rounds the photo looks visibly degraded. If you're going to edit, save as PNG or TIFF mid-flow, then export to JPG once at the end.

PNG — the lossless backbone

Released 1996. Lossless compression, supports transparency, supports indexed color (palette-based) for tiny file sizes on simple graphics.

Strengths: transparency, lossless (can re-save infinitely), great for screenshots and graphics.

Weaknesses: much larger than JPG for photos. A 1MB photo as JPG might be 4MB as PNG.

The two PNG modes:

PNG-24: 16 million colors plus alpha transparency. What most tools save by default. Best for photos and complex graphics.
PNG-8: 256-color palette plus optional 1-bit transparency. What every old icon and screenshot used. Tiny file sizes for simple images.

If you've got a logo with three colors on it, PNG-8 is often 10× smaller than PNG-24 with no visible difference. Most modern tools auto-pick or let you choose; older ones default to PNG-24 and waste space.

When to use PNG over WebP/AVIF: when you need maximum compatibility (very old browsers, email clients, system-level previews on outdated OSes) or when you need lossless preservation for further editing.

WebP — Google's modern compromise

Released 2010, mainstream-ready by 2018. Both lossy and lossless modes, supports transparency, supports animation. Compresses 25–35% smaller than JPG at equivalent quality, 26% smaller than PNG losslessly.

Strengths: smaller files than JPG/PNG with comparable quality, transparency, animation, supported in every modern browser.

Weaknesses: the encoder is slower than JPG. Not supported in some legacy email clients or very old browsers (IE11, but we don't care). Some image-editing tools still don't open WebP natively.

Browser support: universal in modern browsers as of 2020. Safari was last to adopt it (Safari 14, 2020). If you can require Safari 14+, you can serve WebP unconditionally.

Practical note: WebP wins biggest on photos that have lots of smooth gradients. On hard-edged graphics (UI screenshots, line art) the savings over PNG are smaller — sometimes WebP is even larger. Test both before assuming WebP is smaller.

AVIF — the newest, smallest, slowest to encode

Based on the AV1 video codec. Released 2019, broadly supported by 2023. Compresses 30–50% smaller than JPG at similar quality, often 20% smaller than WebP.

Strengths: the smallest file size of any common format. Supports transparency, HDR, and wide color gamuts.

Weaknesses: slow to encode (5–10× slower than JPG), some image tools and CDNs still don't support it, decoding on low-end devices can be slow.

Browser support: Chrome 85+, Firefox 93+, Safari 16.1+. As of 2026, support is broad enough to ship — but always serve a JPG/WebP fallback for the long tail.

When to use: when you have build-time image optimization, you're shipping a lot of photos, and bandwidth or LCP scores matter. For one-off images uploaded by users at runtime, the encoding cost may not be worth it.

HEIC — the iPhone format your build pipeline doesn't speak

HEIC (High-Efficiency Image Container) is what iPhones save photos as by default since iOS 11 (2017). Compresses about 50% smaller than JPG at equivalent quality. Apple ecosystem treats it as native; everything else treats it as a problem.

Strengths: dramatic file-size savings, supports HDR, transparency, and burst sequences.

Weaknesses: patent-encumbered, no native browser support (Safari supports it system-wide but not in <img> tags), most non-Apple tools can't open it.

The practical issue: users upload HEICs to your web app from iPhones, and your backend can't process them. They show up as broken images, fail to thumbnail, error out in image-processing pipelines.

Solutions:

Server-side conversion to JPG or WebP on upload. Libraries like heif-convert or sharp (with libheif) handle this.
Client-side conversion before upload, using a HEIC-to-JPG tool. There's a browser-based HEIC to JPG converter at imagetools.renderlog.in if you want to test what your users are uploading. It runs entirely in the browser, so the photo never leaves the device.
Configure iPhone to save as JPG. Settings → Camera → Formats → Most Compatible. Most users don't know this exists.

SVG and GIF — quick mentions

SVG (Scalable Vector Graphics). Vector format, scales infinitely, tiny file sizes for icons and logos. Use for: icons, logos, simple illustrations. Don't use for: photographs (impossible) or anything with realistic shading.

GIF. Released 1987. Use for: nothing, ideally. Supports animation but at terrible compression — a 5-second GIF is often 10× larger than the same content as an MP4 or WebP. The only legitimate modern use is as a fallback for environments that don't support video tags.

Serving multiple formats

The browser-friendly way to serve modern formats with fallbacks is the <picture> element:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600">
</picture>

Browsers pick the first format they support. If all three are present, modern browsers get AVIF, slightly older ones get WebP, anything else falls back to JPG.

The build pipeline to generate all three is straightforward with tools like sharp, squoosh, or vite-imagetools. If you're not generating multiple formats automatically, you're leaving 20–40% of bandwidth on the floor.

Common conversions and where they bite

A few real-world conversion paths and what to watch for:

JPG → WebP: safe and lossless if you keep quality high; verify color space (some tools accidentally drop sRGB profiles).
PNG → JPG: loses transparency. Anything that was transparent becomes opaque white (or black, depending on the tool).
HEIC → JPG: lossy; once converted, you can't get the HEIC quality back.
WebP → PNG: lossless if the source was lossless WebP; lossy WebP converted to PNG looks fine but doesn't recover detail.
AVIF → anything: generally works, but very high-quality AVIF can produce huge PNGs.

If you're doing one-off conversions while building, imagetools.renderlog.in has dedicated converters for the common pairs — WebP to JPG, HEIC to JPG, JPG to WebP, PNG to WebP, and an image compressor for size targets. All client-side.

TL;DR

Format	When to use	Notes
JPG	Photos, broad compatibility	Quality 75–85 sweet spot; don't re-save repeatedly
PNG	Screenshots, transparency, graphics	PNG-8 for simple images is often 10× smaller
WebP	Modern web replacement for JPG/PNG	25–35% smaller, universal support since 2020
AVIF	Photos with build-time optimization	Smallest, slowest to encode, ship with fallback
HEIC	Receiving from iPhones	Convert to JPG/WebP on upload
SVG	Vector graphics	Icons, logos, never photos
GIF	Legacy fallback only	Use WebP or video instead

Set your build pipeline to generate AVIF + WebP + JPG, serve them through <picture>, and forget about format until the next refactor. Your users save bandwidth, you save Core Web Vitals points, everyone wins.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

Building Slugs That Don't Break: Unicode, Diacritics, and Edge Cases

Ashish Kumar — Sat, 25 Apr 2026 13:47:22 +0000

You ship a blog. The first international post is titled "Café au Lait — A Morning Routine." Your slug generator turns that into /caf-au-lait--a-morning-routine. The double hyphen is ugly, the dropped accent is worse, and that's just the start of what naive slug generation gets wrong.

This is one of those problems that looks like it deserves five lines of regex and ends up needing four hours and a battle-tested library. Let's walk through what actually goes wrong, why, and the rules a slug generator should follow.

What a slug needs to be

A slug is the human-readable part of a URL: in /blog/why-rust-matters, the slug is why-rust-matters. Good slugs have four properties:

URL-safe — contains only characters that don't need percent-encoding in a URL path
Readable — a human can guess what the page is about from the slug alone
Stable — the same input produces the same slug, forever
Unique — within whatever scope (your blog, your products) two pieces of content don't collide

The naive approach trips on every single one of these.

The five-line slug generator and why it's broken

Most engineers, including me, the first time, write something like this:

function slugify(input) {
  return input
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-|-$/g, '')
}

It works on "Hello World" → "hello-world". It also produces these:

"Café au Lait" → "caf-au-lait" (lost the accent, ugly)
"100% Pure" → "100-pure" (dropped the meaning)
"C++ Programming" → "c-programming" (lost the distinguishing feature)
"日本語入門" → "" (empty string — the entire title is gone)
"Hello World" → "hello---world" (multiple spaces become multiple hyphens)
"Hello-World" → "hello-world" (collides with the natural slug)

And these are just the easy cases.

Step 1: Unicode normalization

The first thing a real slug generator does is normalize Unicode. The character é can be represented two ways:

NFC (composed): one code point, U+00E9
NFD (decomposed): two code points, e (U+0065) followed by ◌́ (U+0301, combining acute accent)

These look identical on screen but have different byte sequences. If your slug code only handles one form, the other slips through unchanged.

The fix is simple — normalize first, strip the diacritics second:

function stripDiacritics(input) {
  return input.normalize('NFD').replace(/[\u0300-\u036f]/g, '')
}

stripDiacritics("Café au Lait")  // → "Cafe au Lait"
stripDiacritics("naïve")          // → "naive"
stripDiacritics("Renée")          // → "Renee"

The \u0300-\u036f range covers the combining marks block — once é is decomposed into e + combining accent, the regex strips just the accent.

This handles most European languages but not all of them. German ß doesn't decompose; it should be transliterated to ss. Polish ł doesn't decompose either. For broad European coverage you need a transliteration map, not just NFD normalization.

Step 2: Transliteration vs dropping

For non-Latin scripts (Chinese, Japanese, Arabic, Hindi, Cyrillic), you have a real decision to make:

Option A: Transliterate. 日本語 becomes nihongo. The slug is readable to a Latin-alphabet reader, but transliteration is lossy and language-specific (東京 → tokyo requires knowing it's Japanese, not Chinese, where it'd be dongjing).

Option B: Pass through. Modern URLs support Unicode. /日本語 is a valid URL, browsers display it correctly, and search engines index it. The slug becomes meaningful to readers of that language.

Option C: Generate from a separate field. Many blogs let authors set a slug manually for non-Latin titles. The slug is whatever the author types, the title is whatever they meant.

There's no universally right answer. WordPress transliterates by default. Ghost passes through. Most documentation systems use option C. Pick based on your audience.

Step 3: Punctuation that means something

100% off shouldn't become 100-off. The % carries information. Battle-tested slug libraries have a symbol map that converts meaningful punctuation into words:

const symbolMap = {
  '&': 'and',
  '%': 'percent',
  '@': 'at',
  '+': 'plus',
  '$': 'dollar',
  '€': 'euro',
  '£': 'pound',
  '#': 'hash',
}

This is opinionated — 100% off → 100-percent-off is more readable than 100-off, but plenty of teams just drop the symbol. Decide once, document it.

For programming languages and tech terms specifically: C++ → cpp, C# → csharp, .NET → dotnet. These are conventions, not deductions; a generic slug library won't get them right unless you tell it to.

Step 4: The collision problem

You publish "Hello World." The slug is hello-world. Six months later, you publish another "Hello World" — maybe a follow-up, maybe a different topic that happens to share a title. What's the second slug?

Common patterns:

Numeric suffix: hello-world, hello-world-2, hello-world-3
Date suffix: hello-world-2026-04
ID suffix: hello-world-a3f9

The numeric suffix is the most common and almost always wrong. It encourages people to delete and republish to "get the clean URL", which breaks every link to the original. Date suffixes are the most stable. ID suffixes look ugly but never collide.

Whatever you pick, never silently overwrite an existing slug. Either reject the new content with an error, or generate a unique variant. Slugs that change break every backlink, RSS feed, social share, and search index.

Step 5: Reserved words

If your slug generator ever produces admin, api, login, logout, settings, signup, register, or dashboard, you've got a problem. Either:

The slug now masks an actual route (/blog/admin works fine, but /admin doesn't)
Or, worse, the route works and a user can SEO-impersonate your admin page

Real slug libraries maintain a reserved-words list. Yours should too:

const RESERVED = new Set([
  'admin', 'api', 'app', 'auth', 'dashboard', 'login', 'logout',
  'register', 'settings', 'signup', 'help', 'support', 'about',
  // ...add anything specific to your app
])

if (RESERVED.has(slug)) slug = `${slug}-post`  // or reject

Step 6: Length limits

There's no formal URL length limit, but practical ones exist:

Most CDNs and proxies cap at 2KB for the full URL.
Email clients truncate links over 80 characters in plain-text emails.
Search engines display only the first ~60 characters of a slug in results.

Cap slugs at 60–80 characters, truncated at a word boundary:

function truncate(slug, max = 60) {
  if (slug.length <= max) return slug
  const cut = slug.lastIndexOf('-', max)
  return slug.slice(0, cut > 0 ? cut : max)
}

The lastIndexOf('-', max) ensures we cut at a hyphen, not mid-word.

Putting it all together

A real slug function looks like this:

function slugify(input, { maxLength = 60 } = {}) {
  return input
    .normalize('NFKD')
    .replace(/[\u0300-\u036f]/g, '')        // strip diacritics
    .replace(/[&]/g, ' and ')                // expand symbols
    .replace(/[%]/g, ' percent ')
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')             // non-alphanumeric → hyphen
    .replace(/^-+|-+$/g, '')                 // trim hyphens
    .slice(0, maxLength)
    .replace(/-+$/, '')                      // re-trim after slice
}

That's the floor. From there you'd add the reserved-words check, the collision handler, and (for non-Latin support) either transliteration or pass-through Unicode handling.

Use a library — but know what it does

For production use, don't write this yourself. Battle-tested options:

slugify (npm) — handles transliteration for major European languages, fast, good defaults.
@sindresorhus/slugify — more aggressive transliteration, more configuration knobs.
github-slugger — what GitHub uses for anchor links in READMEs. Predictable, simple.
speakingurl — the most thorough, supports the most languages, also the most overhead.

For a one-off — generating a slug while drafting, testing edge cases, or comparing two slug strategies — paste the title into a browser-based slug generator and see what falls out. It runs locally, so internal product names and unreleased post titles don't end up on a third-party server.

TL;DR

The five-line slug regex breaks on Unicode, symbols, collisions, and reserved words.
Normalize Unicode (NFD), strip combining marks, decide between transliterate vs pass-through for non-Latin scripts.
Map meaningful symbols (% → percent, & → and) — don't silently drop them.
Maintain a reserved-words list. Cap slugs at 60–80 chars, cut on word boundaries.
Never silently overwrite a slug; suffix or reject. Backlinks break forever otherwise.
For everything beyond a one-off, use a library — slugify or @sindresorhus/slugify.

Slug generation is one of those problems that's easy to get 80% right and hard to get the last 20%. Worth doing properly once, then forgetting about.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

Building Offline-First Web Apps with localStorage: A Practical Guide

Ashish Kumar — Sat, 25 Apr 2026 13:46:32 +0000

You're building a tiny tool. Maybe a notepad. Maybe a settings panel. Maybe a draft autosave for a form. You don't want a database. You don't want a backend. You don't even want a login.

localStorage.setItem(key, value) solves the problem in one line and you go home. Until your tool grows up, the data outgrows 5MB, three browser tabs trip over each other, the user clears their cookies, and suddenly you have a support ticket that boils down to "I lost my work."

This is the localStorage post I wish I'd had three years ago. When it's the right tool, when it isn't, and the specific footguns that make production-grade local persistence harder than it looks.

What localStorage actually is

localStorage is a synchronous key-value store, scoped to an origin (protocol + domain + port), persisted to disk by the browser. Both keys and values are strings. That's the whole interface:

localStorage.setItem('username', 'jane')
const value = localStorage.getItem('username')  // 'jane'
localStorage.removeItem('username')
localStorage.clear()

It's been in every browser since 2009. It has no expiration, survives reboots, and is shared across all tabs of the same origin. It's also the most misunderstood persistence API on the web.

When localStorage is actually the right tool

It's right for:

User preferences — theme, language, layout choices, "I dismissed this banner."
Draft state — a form you want to autosave, a half-written note, an unsaved edit.
Auth-adjacent data — user ID, role, last-known username (NOT auth tokens; we'll come back to that).
Small caches — a list of recent searches, a sidebar's collapsed/expanded state.
Feature flags that the user controls — "I opted into the beta UI."

The pattern: small, simple, doesn't need querying, fits in tens of KB, and losing it is annoying but not catastrophic.

It's wrong for:

Large datasets — anything past 1–2 MB starts to pinch
Structured data you need to query — localStorage is dumb storage; no indexes, no transactions
Anything sensitive — accessible by any JS on the page (XSS = full data theft)
Data shared across origins — localStorage is origin-scoped
High-write-frequency state — synchronous writes block the main thread

The footguns

Most production localStorage bugs come from one of these.

1. Everything is a string

setItem stringifies whatever you pass it, but not in a clever way. Numbers become strings. Booleans become strings. Objects become "[object Object]".

localStorage.setItem('count', 5)
localStorage.getItem('count')  // '5' — string, not number

localStorage.setItem('enabled', true)
localStorage.getItem('enabled')  // 'true' — string

localStorage.setItem('config', { dark: true })
localStorage.getItem('config')  // '[object Object]' — useless

Always JSON.stringify and JSON.parse for non-string data:

localStorage.setItem('config', JSON.stringify({ dark: true }))
const config = JSON.parse(localStorage.getItem('config'))

The wrap functions:

function setJSON(key, value) {
  localStorage.setItem(key, JSON.stringify(value))
}

function getJSON(key, fallback = null) {
  const raw = localStorage.getItem(key)
  if (raw === null) return fallback
  try { return JSON.parse(raw) } catch { return fallback }
}

The try/catch is not optional. If the user (or a previous bug) wrote bad JSON, JSON.parse throws, your app breaks on load, and now you can't even fix it through normal flows because the broken data is the first thing you read.

2. The 5MB limit (which isn't really 5MB)

The spec says "the user agent should limit the total amount of space allowed for storage areas." Most browsers settled on 5MB per origin, but it's not enforced uniformly:

Chrome: ~5MB per origin
Firefox: 5MB per origin, configurable
Safari: ~5MB; sometimes silently caps at less
Mobile Safari in private mode: 0 (writes throw QuotaExceededError)

The 5MB is total — keys + values + a small overhead. Strings are stored as UTF-16, so each character is 2 bytes; a "5MB" budget is really 2.5 million characters.

When you exceed the limit, setItem throws a DOMException. You need to catch it:

try {
  localStorage.setItem(key, bigValue)
} catch (e) {
  if (e.name === 'QuotaExceededError') {
    // Make space, or warn the user, or fall back to IndexedDB
  } else {
    throw e
  }
}

If you're storing user-generated content, this happens in production eventually. Plan for it.

3. The synchronous API blocks the main thread

Every setItem call writes to disk synchronously. For small values, this is microseconds. For large values, especially on mobile, it can be tens of milliseconds — long enough to drop a frame.

If your app is autosaving every keystroke and saving 100KB of state each time, you've got a stutter problem. The fix: debounce.

let saveTimer = null
function scheduleSave(state) {
  clearTimeout(saveTimer)
  saveTimer = setTimeout(() => {
    setJSON('app-state', state)
  }, 500)
}

For genuinely large state, this still won't be enough. That's the IndexedDB threshold.

4. Cross-tab synchronization

Two tabs of your app are open. The user changes a setting in tab A. Tab B doesn't know — it's still showing the old value.

The fix is the storage event:

window.addEventListener('storage', (e) => {
  if (e.key === 'theme') {
    applyTheme(e.newValue)
  }
})

The catch: the storage event only fires in other tabs, not the one that did the write. So the writer needs to update its own UI separately, and the listeners pick up changes from elsewhere. This is correct behavior but easy to mishandle.

5. Versioning your stored data

You ship v1 of your app. It writes user state shaped like:

{ "name": "Jane", "color": "blue" }

Six months later, you ship v2. The state shape is now:

{ "user": { "name": "Jane", "preferences": { "color": "blue" } } }

Existing users have v1 data sitting in localStorage. When v2 loads it, things break.

The fix: version your stored data and migrate.

const CURRENT_VERSION = 2

function loadState() {
  const raw = getJSON('app-state', null)
  if (!raw) return defaultState()

  if (raw.version === undefined || raw.version === 1) {
    return migrate1to2(raw)
  }
  if (raw.version === 2) return raw
  // Unknown future version — bail
  return defaultState()
}

Migration is a one-way door. Once you ship v2, you can't easily walk it back without losing data. So design migrations carefully and test them with real v1 data before deploying.

6. Don't store auth tokens here

This is its own essay, but quickly: any XSS vulnerability on your site lets an attacker do localStorage.getItem('auth-token') and steal it. Cookies marked httpOnly aren't accessible to JavaScript, which is what you want for credentials. Use cookies for auth; use localStorage for non-sensitive state.

If you're inheriting a codebase that puts JWT tokens in localStorage, plan to migrate. The migration isn't trivial (CSRF protection, cross-origin handling) but it's worth doing.

When to graduate to IndexedDB

The threshold is roughly:

Data above 5MB — localStorage will cap out
You need querying — finding records by anything other than primary key
Many writes per second — IndexedDB is async and won't block the main thread
Binary data — Blobs, Files, ArrayBuffers store natively in IndexedDB; localStorage forces base64 encoding (33% size overhead)

IndexedDB is more complex (the API is famously verbose), but libraries like idb-keyval give you a localStorage-like wrapper for the simple cases:

import { get, set } from 'idb-keyval'

await set('user-state', complexObject)
const state = await get('user-state')

That's IndexedDB with the same ergonomics as localStorage, but without the 5MB limit and without blocking.

A real case study: a private notepad

A small browser-based notepad — text editor, multiple tabs, autosave, no signup, fully local — is the kind of app that's a perfect localStorage fit until it isn't.

The version that works for 95% of users:

const STORAGE_KEY = 'notepad-tabs-v1'

function loadTabs() {
  return getJSON(STORAGE_KEY, [{ id: 'default', content: '' }])
}

function saveTabs(tabs) {
  setJSON(STORAGE_KEY, tabs)
}

// Debounce on every keystroke
const debouncedSave = debounce(saveTabs, 300)

This works perfectly until a user pastes a 4MB log file into one tab. Then setItem throws, the tab data fails to save, and on reload everything is back to the previous state. The user thinks they lost their work.

The graduation path: when total size approaches 1MB, migrate that tab's content to IndexedDB and store just a pointer in localStorage. Most users never trip the migration; the heavy users get a more capable backend automatically.

This is what notepad.renderlog.in does — small notes stay in localStorage for instant load, larger ones move to IndexedDB transparently, nothing ever leaves the browser. The whole thing is single-page, no signup, works offline after the first load, just a working text editor that respects the user's privacy. Useful as a reference if you're designing similar offline-first state.

TL;DR

localStorage is great for: preferences, drafts, small caches, non-sensitive flags. ~10–500KB of data.
Always JSON.stringify/JSON.parse non-string values; always try/catch the parse.
The 5MB limit is real and hits in production. Catch QuotaExceededError.
Synchronous writes block the main thread; debounce frequent saves.
Use the storage event for cross-tab sync.
Version your stored data from day one — migrations cost you nothing now and save you everything later.
Don't store auth tokens. Use httpOnly cookies.
Graduate to IndexedDB (via idb-keyval or similar) for >5MB, querying, or binary data.

localStorage is one of those APIs that looks too simple to think about and turns out to deserve about a day of design. Spend the day; you'll save the support tickets.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

The WiFi QR Code Format Decoded: Build One Yourself in 30 Lines

Ashish Kumar — Sat, 25 Apr 2026 13:46:27 +0000

You've scanned one a hundred times. The cafe printed a QR code, you pointed your phone at it, and you joined their WiFi without typing the 32-character password. What's actually encoded in that little black-and-white square?

The answer is shorter than you'd guess. The WiFi QR format is one of the cleanest specs you'll find — six fields, plain text, no binary encoding, no cryptography. You can build a generator from scratch in thirty lines of JavaScript, which we'll do at the end of this post.

But there are gotchas. Special characters in passwords break naive implementations. iOS and Android handle the same QR slightly differently. And the WPA3 transition is starting to break older codes in subtle ways.

The format

A WiFi QR code is just a text string in this shape:

WIFI:T:WPA;S:NetworkName;P:password123;;

That's the entire format. The QR code itself is just standard text encoding (any QR code library handles it); the magic is in the string format. Six possible fields, separated by semicolons:

Field	Meaning	Required?
`T`	Authentication type	Yes
`S`	SSID (network name)	Yes
`P`	Password	Required for WPA/WEP
`H`	Hidden network (true/false)	Optional
`E`	EAP method (for enterprise)	Optional
`I`, `A`	Identity, anonymous identity (enterprise)	Optional

The WIFI: prefix tells the scanner "this isn't a URL or plain text — treat it as a WiFi config." Two trailing semicolons close the structure.

The auth types

The T: field accepts:

WPA — covers WPA, WPA2, and WPA3 (most home and business networks)
WEP — legacy, broken since 2007, you shouldn't see it but you will
nopass — open networks, no password (P field omitted)

There's no separate WPA2 or WPA3 — they all go under WPA. The actual encryption negotiated is whatever the access point supports; the QR just tells the device "expect a password-protected network."

Examples:

Open coffee-shop WiFi:
WIFI:T:nopass;S:Cafe Free WiFi;;

Standard home network:
WIFI:T:WPA;S:MyHomeWiFi;P:correcthorsebatterystaple;;

Hidden network:
WIFI:T:WPA;S:OfficeNet;P:s3cret;H:true;;

The escaping rules (where naive implementations break)

Here's where it gets interesting. Five characters are special and must be backslash-escaped if they appear in the SSID or password:

\ (backslash) — escape character itself
; (semicolon) — field separator
, (comma) — used in some implementations
: (colon) — field key/value separator
" (double quote) — used to wrap special values

Common case: passwords with semicolons. MyP;ssword must be encoded as MyP\;ssword in the QR. Without the escape, the parser thinks the password is MyP and ssword is a new field.

Here's a real escape function:

function escapeWifi(value) {
  return value.replace(/[\\;,:"]/g, '\\$&')
}

The $& in the replacement is the matched character itself, prefixed with a backslash.

There's a second, weirder rule: if the SSID or password is entirely a hexadecimal string (e.g., "DEADBEEF1234"), it must be wrapped in double quotes to disambiguate from a hex-encoded value. This is rare in practice but spec-compliant tools do handle it:

function isHex(s) {
  return /^[0-9a-fA-F]+$/.test(s) && s.length % 2 === 0
}

function formatField(value) {
  const escaped = escapeWifi(value)
  return isHex(value) ? `"${escaped}"` : escaped
}

If you're testing a QR generator, try a password of 1234567890ABCDEF — that's the case where the quotes matter.

Hidden networks and why they're optional-but-not

The H:true field tells the device "this is a hidden network, don't expect to see it in the scan list." Without it, scanning a hidden-network QR sometimes works, sometimes doesn't, depending on whether the device can find the SSID by passive scanning.

Practical advice: if you've configured your network as hidden (which I'd argue you shouldn't — it's security theater and breaks discovery), include H:true. If your network is broadcasting normally, omit it. Some Android implementations behave oddly when H:false is explicitly set vs omitted; safer to leave it out unless needed.

Enterprise networks (EAP)

For 802.1X / WPA-Enterprise networks (most large offices and universities), the format extends:

WIFI:T:WPA;S:CorpNet;E:PEAP;P:password;I:username;;

The E field specifies the EAP method (PEAP, TTLS, TLS). The I field is the user identity. Anonymous identity (A) is sometimes used.

In practice, this is often easier to handle through a profile (.mobileconfig for iOS, eap_config for Android) than through a QR code, because enterprise auth has too many knobs (CA certs, server name validation, inner auth method) to fit into a QR comfortably. Most tools that "support enterprise QR" generate something that works on the latest Android and quietly fails on iOS.

Building one in 30 lines

Putting it all together, here's a complete generator:

function escapeWifi(value) {
  return value.replace(/[\\;,:"]/g, '\\$&')
}

function isHex(s) {
  return s.length > 0 && /^[0-9a-fA-F]+$/.test(s) && s.length % 2 === 0
}

function formatField(value) {
  const escaped = escapeWifi(value)
  return isHex(value) ? `"${escaped}"` : escaped
}

function buildWifiString({ ssid, password, auth = 'WPA', hidden = false }) {
  if (!ssid) throw new Error('SSID is required')
  if (auth !== 'nopass' && !password) {
    throw new Error('Password required for ' + auth)
  }

  const fields = [`T:${auth}`, `S:${formatField(ssid)}`]
  if (auth !== 'nopass') fields.push(`P:${formatField(password)}`)
  if (hidden) fields.push('H:true')

  return 'WIFI:' + fields.join(';') + ';;'
}

// Convert to QR — using any QR library
import QRCode from 'qrcode'

async function makeWifiQR(opts) {
  const text = buildWifiString(opts)
  return await QRCode.toDataURL(text)
}

// Usage
const dataUrl = await makeWifiQR({
  ssid: 'CafeWiFi',
  password: 'latte;art',  // semicolon will be properly escaped
  auth: 'WPA',
})

That's a real, spec-compliant WiFi QR code generator. About 30 lines including the QR rendering. The qrcode npm package handles the actual visual rendering; the format string is the part that matters.

iOS vs Android: where they differ

Both platforms support the format, but with subtle differences:

iOS (since iOS 11) reads WiFi QR codes through the Camera app — you point, a notification appears, tap to join. Works seamlessly for WPA and nopass. Hidden networks (H:true) often don't auto-join on iOS — the network has to already be known.
Android scanners vary. The native camera works on most modern Android versions. Some manufacturer skins (older Samsung, some Xiaomi) require a third-party scanner. Hidden networks generally work better on Android than iOS.
Special characters sometimes survive iOS but break Android, or vice versa. Test with &, %, and emoji-bearing SSIDs (yes, those exist) before assuming a code is universal.

The reliable subset: T:WPA or T:nopass, ASCII passwords, broadcasting (non-hidden) networks. Stick to that and you'll have no issues across phones.

The WPA3 transition

WPA3 networks are starting to roll out. The QR format doesn't change — T:WPA still works. But there's a new mode called "WPA3-Personal SAE" that requires the device to support SAE authentication. Older devices joining a WPA3-only network from a QR code will fail to connect even though the QR scans correctly.

Most WPA3 routers are configured for "WPA2/WPA3 transition mode" by default, which means older devices fall back to WPA2. If you're building a public WiFi QR code (cafe, hotel), keep your AP in transition mode unless you have a reason not to. WPA3-only networks will silently fail for a chunk of guests.

Beyond WiFi: the format pattern

The WiFi QR format is one of several "structured QR" specs. Others you'll see:

vCard: BEGIN:VCARD\nVERSION:3.0\nFN:John Doe\n... — for contact cards
mailto: mailto:hello@example.com?subject=Hi&body=... — for email
tel: tel:+15555555555 — for phone numbers
geo: geo:37.7749,-122.4194 — for map locations
SMSTO: SMSTO:+15555555555:Hello — for pre-composed SMS

All of them are just text. The "smart" behavior happens because phone scanners recognize the prefix and offer the appropriate action.

When you need to make one quickly

For one-offs — sharing your home WiFi with a guest, posting one for an office network, generating a batch for a hotel — there's no need to write code. qrtools.renderlog.in has a WiFi QR code generator that handles the escaping correctly, plus generators for vCard (contact info), UPI (payment QRs popular in India), and bulk QR generation for if you ever need to print 200 different ones at once. Everything renders client-side, so passwords don't end up in any server log.

TL;DR

WiFi QR codes are just text in this format: WIFI:T:WPA;S:name;P:password;;
Escape \, ;, ,, :, " in the SSID and password — the most common bug in homemade generators.
Hex-only strings should be wrapped in double quotes.
T:WPA covers WPA2 and WPA3; there's no separate WPA3 mode.
iOS reads them via the Camera; Android via the native scanner. Both handle the basics, both have edge cases with hidden networks and special characters.
The whole thing is ~30 lines of JavaScript on top of a QR library.
For one-offs, browser-based generators handle the escaping correctly and don't ship your password through a server.

The format has lasted 15 years without a major revision, which is rare in tech. Worth understanding once, useful forever.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

Naming Things: When to Use camelCase, snake_case, kebab-case, and PascalCase

Ashish Kumar — Sat, 25 Apr 2026 13:46:00 +0000

There are two hard problems in computer science: cache invalidation, naming things, and off-by-one errors. The naming-things one is the only one we can actually argue about all afternoon, so we do.

This post is a practical reference for when each casing convention is correct, where they collide (databases meet APIs meet frontends meet URLs), and how to handle the conversions without sprinkling _.camelCase() calls across your codebase like prayers.

The five conventions you'll see

Convention	Example	Where it lives
camelCase	`userEmail`	JavaScript variables, JSON keys, Java/Swift methods
PascalCase	`UserEmail`	Class names, type names, React components, C# everything
snake_case	`user_email`	Python variables, SQL columns, Ruby methods, env vars (sort of)
kebab-case	`user-email`	URLs, CSS classes, HTML attributes, file names, npm packages
SCREAMING_SNAKE_CASE	`USER_EMAIL`	Constants, environment variables

That's the picture. The rest of the post is about why each one ended up where it did, and what to do when you have to cross between them.

camelCase — the JavaScript default

JavaScript has used camelCase since the language existed. Variable names, function names, object keys, parameter names — all camelCase. The DOM API uses it (document.querySelector, addEventListener), browser globals use it, every framework follows it.

const userEmail = 'jane@example.com'
function isValidEmail(input) { /* ... */ }
fetch('/api/users').then(res => res.json())

Java, Swift, Kotlin, and TypeScript also use camelCase for variables and methods (PascalCase for classes). If you're writing in any of these languages and the team convention is "use camelCase", that's not a stylistic preference; that's the language convention.

One exception worth knowing. Some JavaScript codebases use snake_case for properties that come straight from the database or from a Python/Ruby API to avoid mid-flight conversion bugs. It's a defensible choice, but it does leak the backend's convention into the frontend forever.

PascalCase — for things that get instantiated

PascalCase (which is just camelCase with the first letter capitalized) signals "this is a type, not a value." Used for:

Classes: class UserRepository {}
TypeScript types and interfaces: interface User {}, type LoginResult = ...
React components: function UserAvatar({ user }). JSX literally requires this — <userAvatar /> is treated as an HTML element, <UserAvatar /> as a component.
Enum values in some style guides: enum Status { Active, Pending, Banned }

The mental model: if you can new it, type-check against it, or render it as a component, it's PascalCase. If it's a value you read or call, it's camelCase. Mostly that line is sharp; once in a while you'll see a class meant to be used like a singleton (Math, JSON) and the line blurs.

snake_case — Python, SQL, and the systems layer

snake_case dominates Python (PEP 8 mandates it), SQL columns (most style guides at least), Ruby, Rust (mostly), and any language that came out of the Unix systems-programming world.

def get_user_by_id(user_id):
    return db.query("SELECT user_email FROM users WHERE id = %s", (user_id,))

The trade-off vs camelCase is readability of long names: get_user_by_id is slightly easier to read than getUserById for most people, especially with screen readers. The cost is that snake_case is one extra character per word boundary, which adds up in 50,000-line codebases.

Environment variables are kind of snake_case but uppercase: DATABASE_URL, API_KEY, NODE_ENV. This is convention from POSIX, and it's universal — never use lowercase or camelCase for env vars. Tools assume uppercase.

kebab-case — anywhere a hyphen is legal and an underscore isn't

This is the rule. kebab-case lives wherever syntax permits hyphens but not underscores (or where hyphens are the established convention):

URLs: /blog/why-rust-matters. Search engines parse hyphens as word separators; underscores get treated as part of one word.
CSS class names: .user-avatar, .is-active. Conventions like BEM lean hard on kebab-case.
HTML attributes: data-user-id, aria-label.
CLI flags: --dry-run, --no-color.
npm package names: lodash, eslint-plugin-react. Underscores are technically allowed but discouraged.
File names in many ecosystems: user-service.ts, 404-not-found.html.

Why hyphens for URLs specifically? Because /blog/why_rust_matters shows up in Google search ranking as one word ("why_rust_matters") rather than three. The SEO impact is real.

SCREAMING_SNAKE_CASE — constants and signals

The all-caps form is a signal that says "this value is fixed at build/deploy time, not runtime."

const MAX_RETRIES = 5
const DEFAULT_TIMEOUT_MS = 30_000
const FEATURE_FLAGS = ['beta-search', 'new-checkout']

DATABASE_URL = os.environ['DATABASE_URL']
DEBUG = False

In JavaScript, this convention is fading — some style guides treat all const as constant enough to use camelCase, reserving SCREAMING_CASE only for truly immutable, module-scoped values. Pick a rule and apply it consistently; what kills readability is a codebase where some constants are uppercase and some aren't with no rule.

Where conventions collide

Real applications cross between conventions constantly. The friction points:

Database to API. Postgres column user_email becomes JSON key userEmail becomes JavaScript variable userEmail. Most ORMs (Sequelize, Prisma, ActiveRecord, SQLAlchemy) handle this automatically with options like underscored: true.

API to URL. A resource called userProfile in your code lives at /user-profile, not /userprofile or /userProfile. URL-case conversion is a 5-line function but the boundary where you do it matters: at the route definition, not at the controller.

File names to imports. import { UserAvatar } from './user-avatar.tsx'. The file is kebab-case, the export is PascalCase. Most teams hold this convention; some force file names to match their default export. Either is fine; pick one.

Env to config. DATABASE_URL becomes config.databaseUrl in code. Don't keep them named identically — that's how secret leaks happen, when someone does console.log(config) and your env shows up in logs.

Conversion is mechanical — make it boring

The single biggest mistake teams make is converting cases by hand, in scattered places, inconsistently. Pick one of these approaches and apply it everywhere:

1. Convert at the boundary. API response gets converted to camelCase as soon as it arrives, before any business logic touches it:

import { camelCase } from 'lodash'
const data = await res.json().then(deepCamelCase)

2. Use a schema layer. Zod, io-ts, or whatever validation library you use can transform field names as part of parsing.

3. Generate the converters. If your API has an OpenAPI spec, generators like openapi-typescript-codegen produce camelCased clients automatically.

For one-off conversions while writing or refactoring, browser tools handle the boilerplate. The text utilities at text.renderlog.in include dedicated converters for each case style — camelCase, snake_case, kebab-case, PascalCase, Title Case, sentence case — useful when you're translating naming for a config schema, generating SQL DDL from a TypeScript type, or wrangling a CSV with mixed-case headers. The whole site runs client-side, so config files and column names don't get uploaded anywhere.

Anti-patterns I see in code review

Mixed cases in one scope. const user_email next to const userName in the same file. Pick one.

Stutter in identifiers. user.userEmail, Order.orderId. The parent object already gives you the namespace; drop the prefix and write user.email, order.id.

Acronyms inconsistently cased. Is it parseHTML or parseHtml? userID or userId? Both work; what's wrong is using both in the same codebase. Most style guides land on "treat acronyms as words" — parseHtml, userId, loadJsonFile. ESLint and most linters can enforce this.

Casing that fights the language. Writing getUserById in Python or get_user_by_id in JavaScript is a hill that's not worth dying on. Match the language's culture.

TL;DR

You're naming a...	Use...
JS/TS variable, JSON key	camelCase
Class, type, React component	PascalCase
Python variable, SQL column	snake_case
URL, CSS class, file name, CLI flag	kebab-case
Build-time constant, env var	SCREAMING_SNAKE_CASE

Pick a rule per layer, enforce it with a linter, convert at boundaries, and don't mix conventions inside one file. When you're switching between cases in your head, browser-based case converters save the muscle memory for the actually hard problem — which is still cache invalidation.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

JSONPath Cheat Sheet: Querying Nested JSON Without Lodash

Ashish Kumar — Sat, 25 Apr 2026 13:45:55 +0000

You've got a 200-line JSON response. You need the email of every user whose lastLogin is older than 30 days, but only from the team department, sorted by id. You start writing a .filter().map() chain and twenty minutes later you're debugging an undefined because one user's meta object is missing.

This is what JSONPath was built for. It's a query language for JSON, the way XPath is for XML. You can write $.users[?(@.lastLogin < @.threshold)].email and skip the imperative gymnastics.

This is the cheat sheet I keep open while writing API tests, debugging GraphQL responses, and combing through CloudWatch logs. Real syntax, real payloads, the operators that actually show up in practice, and the gotchas that catch people who learned JSONPath from one tutorial.

The payload we'll use throughout

{
  "store": {
    "books": [
      { "category": "fiction", "author": "Tolkien", "title": "The Hobbit", "price": 14.99, "tags": ["fantasy", "classic"] },
      { "category": "fiction", "author": "Le Guin", "title": "A Wizard of Earthsea", "price": 12.50, "tags": ["fantasy"] },
      { "category": "tech", "author": "Knuth", "title": "TAOCP Vol 1", "price": 89.00, "tags": ["algorithms"] },
      { "category": "tech", "author": "Crockford", "title": "JavaScript: The Good Parts", "price": 22.00 }
    ],
    "bicycle": { "color": "red", "price": 399.00 }
  }
}

Real-world enough to show off the operators, small enough to keep in your head.

The core syntax (you'll use these every day)

Symbol	Meaning
`$`	The root
`.` or `[]`	Child accessor
`..`	Recursive descent (find anywhere)
`*`	Wildcard (all children)
`[n]`	Array index
`[start:end]`	Array slice
`[?(...)]`	Filter expression
`@`	The current node (inside a filter)

That's roughly the whole language. Everything else is composition.

Walking through real queries

All books:

$.store.books[*]

The [*] is the wildcard form. $.store.books works too if you want the whole array as one result.

The first book's title:

$.store.books[0].title

The last book's title:

$.store.books[-1].title

Negative indices count from the end, like Python. Not all implementations support this — the original Goessner spec didn't, but jsonpath-plus and jq do.

Every author in the document:

$..author

The .. is recursive descent. It searches every depth for a key called author. Useful when you don't know exactly where something lives.

All books with price under $20:

$.store.books[?(@.price < 20)]

The @ inside the filter refers to the current item being checked. This is the operator that makes JSONPath worth learning — it does in one line what takes 5–10 lines of imperative JavaScript.

Just the titles of those books:

$.store.books[?(@.price < 20)].title

Filters compose with subsequent path segments. Cleaner than chaining .filter().map().

Books that have a tags field at all:

$.store.books[?(@.tags)]

A bare @.field evaluates truthy if the field exists. Useful for sparse data.

Books tagged 'fantasy':

$.store.books[?(@.tags && @.tags.indexOf('fantasy') >= 0)]

Or in implementations that support in:

$.store.books[?('fantasy' in @.tags)]

This is where implementations diverge. Some support in, some require indexOf, some have a contains helper. RFC 9535 (the new official spec) standardizes a lot of this, but most libraries you'll touch still follow Goessner's original 2007 draft. Test before you commit.

The first two books (slice):

$.store.books[0:2]

Same syntax as Python slicing. [start:end:step] is also valid in most implementations: $.store.books[::2] for every other book.

Filter operators worth knowing

Inside a [?(...)], you can use:

==, !=, <, <=, >, >= — comparisons
&&, ||, ! — logical operators
=~ — regex match (in some implementations)

Real example — books over $50 OR by Tolkien:

$.store.books[?(@.price > 50 || @.author == 'Tolkien')]

Author names matching a pattern:

$.store.books[?(@.author =~ /^[A-K]/)]

That last one is library-specific. jsonpath-plus supports it; the standard jsonpath package on npm doesn't. If your filter doesn't work, the regex operator is the first thing I'd suspect.

The Goessner / RFC 9535 / jq divergence

Three implementations dominate, and they disagree:

Goessner JSONPath (2007). The original. Most JS libraries follow this. Filters use JavaScript-like syntax. .. recursive descent. No standardized output format.

RFC 9535 (2024). The official IETF standard. Stricter syntax, type-safe filters, no JavaScript expressions, well-defined edge cases. Adoption is still slow — most production tools haven't migrated.

jq. Not actually JSONPath, but does the same job with different syntax. .store.books[] | select(.price < 20) is the equivalent of the filter we wrote above. jq is its own world; if you're already comfortable with it, you don't need JSONPath.

The practical advice: pick a JSONPath library, read its docs, don't assume queries port. The 80% that's identical is the 80% in this cheat sheet.

Where you'll actually use JSONPath

It's not just for browser debugging. JSONPath shows up in:

Postman / Insomnia / Bruno — for assertions in API tests (pm.response.json() returns the body, then JSONPath filters it).
Datadog / Grafana — for extracting values from JSON log entries.
kubectl — kubectl get pods -o jsonpath='{.items[*].metadata.name}'.
AWS CLI — aws ec2 describe-instances --query. Note: AWS uses JMESPath, not JSONPath. They look similar, they aren't.
Browser fetch hooks — middleware that extracts a specific path from every API response.
GraphQL response shaping — though GraphQL has its own query syntax, JSONPath is useful for post-processing.

The skill compounds. Learn it once, use it in five tools.

Common mistakes

1. Forgetting @ inside filters. $.books[?(.price < 20)] is wrong; it should be $.books[?(@.price < 20)]. Easy mistake when you're used to dot-prefixed paths.

2. Quoting numeric comparisons. [?(@.price < '20')] does string comparison, not numeric. The result of comparing strings to numbers is implementation-defined. Drop the quotes.

3. Assuming results are an array. A query that returns one match returns the value, not a one-element array, in some libraries. Always handle both: Array.isArray(result) ? result : [result]. RFC 9535 standardizes around always-an-array; legacy libraries don't.

4. Using .. in a hot loop. Recursive descent walks the entire tree. On a 50,000-line CloudWatch payload, it's measurably slow. Prefer explicit paths when you know the structure.

5. Forgetting that filters short-circuit on missing fields. [?(@.price > 20)] excludes items where price is missing. If you wanted to include them, write [?(!@.price || @.price > 20)].

The fastest way to test queries

When I'm writing JSONPath against a real payload, I don't iterate in code. The feedback loop is too slow. The JSONPath tester on json.renderlog.in lets you paste the JSON, type the query, and see results live — including syntax errors highlighted as you type. The whole thing runs client-side, so production payloads with sensitive data don't get uploaded anywhere.

For one-off transformations of the JSON itself before you query it, the JSON formatter and JSON validator are part of the same workflow. Bookmark all three.

TL;DR

$ is root, @ is current, .. is recursive descent, [?(...)] is a filter.
80% of your queries are $.path[?(@.field op value)].subfield.
Pick one library and stick to it; queries don't always port between Goessner, RFC 9535, and jq.
Test queries in a browser-based JSONPath tester before wiring them into code.
For nested-JSON debugging in general, the same sites usually have a JSON formatter and diff tool — bookmark them together.

JSONPath isn't elegant. It's a fragmented, half-standardized language with three competing implementations and a syntax that looks like 2007 PHP. But it solves a real problem in one line that takes ten lines of .filter().map().reduce() chains, and that's worth learning.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

DEV Community: Ashish Kumar

OPFS: The Browser's Built-in Filesystem Explained

The storage landscape problem

What OPFS actually is

The synchronous access handle why it matters

Worker + OPFS patterns

Streaming writes from the network

Real use case: caching a 200MB WASM binary

OPFS + SQLite: the surprising use case

Storage comparison table

Quota management

Browser support

Wrapping up

Network Optimization in React SPAs: Prefetching

The SPA network problem

HTTP cache headers: the foundation you're probably skipping

Stale-while-revalidate in JavaScript: React Query internals

Request deduplication

Avoiding request waterfalls in React

Prefetching strategies

Resource hints: preconnect, prefetch, preload

Priority Hints

Service Workers for network interception

Connection-aware fetching

What the network tab tells you

Putting it together

DOM Performance on Mobile: Lab vs Real Device Reality

The mobile hardware reality

Chrome DevTools CPU throttling isn't enough

DOM size and style recalculation cost

Mounting discipline: deferring below-fold components

content-visibility: auto

CSS contain property

Touch scroll performance

Scroll jank: the full picture

IntersectionObserver vs scroll events

Input latency: the 300ms tap delay

Images on mobile

Putting it together

React Re-rendering: When and Why Component Trees Update

Render phase vs commit phase

The render phase

The commit phase

Reconciliation and the fiber tree

What triggers a re-render

Re-renders don't mean DOM updates

Why referential equality matters

The context performance problem

Keys in lists: what they actually do

React 18 automatic batching

StrictMode's double-render in development

Reading the React Profiler

OCR in the Browser: How Tesseract.js Makes PDF Text Extraction Free

What OCR is, briefly

Tesseract: 30 years of OCR, now in your browser

The PDF-to-text pipeline

Web Workers for the UI

Language packs

Where OCR falls down

Cloud OCR vs Tesseract.js — when to pick which

A practical caveat: PDFs that already have text

Where to try OCR right now

TL;DR

Why Client-Side PDF Tools Beat Server Uploads (Privacy, Speed, and Cost)

How we ended up uploading PDFs to servers

What changed: pdf.js and WebAssembly

The privacy angle

The speed angle

The cost angle (for tool builders)

The trade-offs (because there always are some)

How to tell if a "free PDF tool" is actually client-side

What's possible client-side now

TL;DR

A Developer's Guide to Image Formats: JPG, PNG, WebP, AVIF, and HEIC

The decision tree

JPG (JPEG) — the workhorse

PNG — the lossless backbone

WebP — Google's modern compromise

AVIF — the newest, smallest, slowest to encode

HEIC — the iPhone format your build pipeline doesn't speak

`content-visibility: auto`

CSS `contain` property