DEV Community: CarsonJ

RTL Is Not a Mirror Toggle: A Practical Checklist for Multilingual Web Tools

CarsonJ — Tue, 20 Oct 2026 02:30:00 +0000

RTL Is Not a Mirror Toggle: A Practical Checklist for Multilingual Web Tools

Most teams treat right-to-left support as a CSS cleanup task: flip a few margins, add dir="rtl", and ship.

That works for a landing page. It breaks quickly in a real tool.

A tool has user-generated text, code, URLs, numbers, progress indicators, keyboard shortcuts, validation messages, and layouts that change with state. Each of those has its own direction rules. I learned this while shipping a small collection of browser-based utilities in English, Chinese, Spanish, French, Hindi, and Arabic. The Arabic interface exposed problems that were invisible in screenshots of the English version.

This is the checklist I now use before calling an interface RTL-ready.

1. Separate document direction from content direction

The page locale sets the default direction, but individual pieces of content do not always follow it.

A URL, email address, code sample, API key, or hexadecimal color is left-to-right even inside an Arabic page. A name or message typed by the user may be either direction. Forcing the whole page direction onto those values produces punctuation in the wrong place and makes copied text harder to read.

Use dir="auto" for unknown user content, and explicitly mark technical values as LTR:

<p dir="rtl">رابط الموقع:</p>
<code dir="ltr">https://example.com/path?q=1</code>

<p>رسالة المستخدم:</p>
<p dir="auto">مرحبا, version 2.0</p>

For inline fragments inside a sentence, <bdi> is often safer than changing the block direction. It isolates the fragment without restructuring the paragraph.

2. Replace physical CSS properties with logical ones

This is the highest-leverage change. Physical properties encode a left-to-right assumption:

/* Fragile */
.card {
  margin-left: 1rem;
  padding-right: 0.75rem;
  border-left: 2px solid;
  text-align: left;
}

Logical properties describe the relationship to the writing direction:

/* Works in both directions */
.card {
  margin-inline-start: 1rem;
  padding-inline-end: 0.75rem;
  border-inline-start: 2px solid;
  text-align: start;
}

The same idea applies to inset-inline-start, border-start-start-radius, and margin-block. Modern browsers support these properties well. A quick search for left, right, margin-left, padding-right, and text-align: left is a useful first audit.

Do not blindly replace every occurrence. A chart axis, a media scrubber, or a coordinate system may intentionally remain LTR. The question is whether the position is physical or semantic.

3. Mirror navigation, not meaning

Directional icons are not all equivalent.

A back arrow, next arrow, breadcrumb chevron, and “continue” icon usually need to mirror in RTL. A checkmark, warning sign, play button, download icon, or brand logo usually does not. A clock still runs clockwise; a volume slider still increases from left to right unless the product deliberately defines it otherwise.

The practical rule is: mirror an icon only when it communicates left-versus-right movement. Use CSS transform: scaleX(-1) on the icon container when mirroring is required, and keep the accessible label unchanged.

Also check progress bars and carousels. A progress bar should fill from the inline start, not always from the left. A carousel’s next button should move toward the inline end. These are behavioral details that a static screenshot will not reveal.

4. Keep numbers, code, and shortcuts LTR

Arabic text can contain Latin digits, Arabic-Indic digits, decimals, negative numbers, percentages, and dates. The surrounding paragraph may be RTL, but the number itself should remain readable as a number.

In forms, set the direction explicitly for fields whose content is technical:

<input type="url" dir="ltr" inputmode="url">
<input type="email" dir="ltr" inputmode="email">
<input type="text" dir="ltr" inputmode="decimal">

Keyboard shortcuts need the same care. “Ctrl + K” is a Latin sequence. Translating the words around it is fine; reversing the key order is not.

5. Test mixed-direction strings, not just translated labels

A locale file can be 100% translated and still produce broken UI. The difficult cases are mixed:

an Arabic sentence containing an English product name
a file name such as report-2026-final.pdf
a path such as C:\Users\name\Documents
a price with a currency symbol
a countdown with units
a validation message that interpolates a user value

Test those cases with real content. Pseudolocalization is useful for finding layout stress, but it does not replace Arabic text. Ask a native speaker to scan the interface, or at minimum use a real Arabic reviewer for the most important workflows.

6. Do not use letter-spacing or uppercase as a universal style

Arabic script is cursive. Large positive letter-spacing can break the visual joining of letters. text-transform: uppercase has no useful effect on Arabic and can create misleading expectations in a mixed-language design system.

Choose fonts with Arabic coverage, then verify line height and weight. A Latin font that looks elegant may fall back to a mismatched Arabic face halfway through the page. Test the actual font stack on Windows, macOS, Android, and iOS if your audience spans those platforms.

7. Audit the whole state machine

RTL bugs often appear after an interaction, not on first load:

Open a dropdown near the inline end.
Trigger an error and inspect the icon and message alignment.
Paste a long URL into an RTL field.
Resize to mobile and open a side panel.
Switch locale while a modal is open.
Use keyboard-only navigation and check focus order.
Copy generated text and paste it into another app.

If the interface stores layout assumptions in JavaScript, such as left: 24, translateX(100%), or scrollLeft, audit those too. CSS logical properties do not fix hard-coded geometry in a canvas or a custom drag interaction.

8. Treat SEO as part of localization

RTL is also a metadata and routing problem. Each language version should have a self-referencing canonical URL, reciprocal hreflang entries, and localized titles and descriptions. Do not point every locale to the English canonical and expect the Arabic page to rank independently.

The HTML direction should match the locale:

<html lang="ar" dir="rtl">

Keep the language code accurate. A page translated into Arabic but marked as English is a confusing signal for both users and search engines.

9. A small pre-release checklist

Before shipping an RTL locale, I check:

No accidental physical margins or absolute left positioning.
All user-generated content has a safe direction strategy.
URLs, code, email addresses, and numeric inputs remain LTR.
Directional icons mirror; semantic icons do not.
Progress and carousel behavior follows the inline direction.
Fonts cover Arabic and mixed-script content.
Focus order and keyboard shortcuts still make sense.
Canonical and hreflang tags are reciprocal.
At least one native or fluent reviewer has used the core workflow.

RTL support is not a theme. It is a set of product decisions about content, geometry, and meaning. The teams that get it right tend to discover fewer “small” bugs after launch, because they stop treating left and right as universal constants.

I maintain Korelyy, a browser-first collection of small utilities. The Arabic text toolbox is one of the interfaces I use to test these ideas in practice. If you are building a multilingual tool, start with the mixed-direction cases; they reveal more than a translated screenshot ever will.

Browser-First Tools Are Quietly Replacing Bloated SaaS Apps

CarsonJ — Mon, 19 Oct 2026 03:13:34 +0000

I have a small test I use before installing another productivity app: does this task actually need a server?

A lot of everyday work fails that test. Renaming a batch of files, counting words, formatting JSON, removing blank lines from a draft, compressing one image, or merging two PDFs does not require an account, a sync engine, a monthly subscription, or a copy of the file sitting in someone else's storage. Yet those are exactly the tasks that often get wrapped in a full SaaS product.

The result is familiar: a 2 MB task comes with a 40 MB interface. You sign up, verify an email, pick a plan, upload a file, wait for a spinner, download the result, and then wonder why the whole thing needed a cloud.

Browser-first tools are not a universal replacement for SaaS. They are a useful default for a narrow class of work: small, well-defined tasks where the input is already on your device and the output can be produced immediately.

The browser became a real runtime

The old objection was that browsers were too limited. That is no longer true for many utility tasks.

Modern browsers expose APIs that cover a surprising amount of ground:

FileReader and Blob for local file access;
Canvas for image resizing and format conversion;
Web Crypto for hashing and encryption primitives;
IndexedDB for local state when persistence is useful;
WebAssembly for heavier parsers and codecs;
Service Workers for offline shells and caching.

A browser-based image compressor, for example, can read a file selected by the user, draw it to a canvas, re-encode it as JPEG, PNG, or WebP, and download the result without sending the original image to a server. A PDF tool can use a client-side library to merge pages and return a new file as a download.

That architecture changes the product conversation. Instead of asking, "How do we get users to create an account?", the first question becomes, "Does the task need to leave the device at all?"

Where browser-first wins

Browser-first is a strong fit when most of these are true:

The task is bounded. The user knows what they want before they open the page.
The input is local. The file or text is already on the device.
The output is immediate. There is no long-running job queue.
Collaboration is not the point. One person can finish the task alone.
The data is sensitive. Uploading it creates risk without adding much value.
The task is occasional. A full account and subscription would be disproportionate.

This is why small utilities are a natural fit. They are not trying to become a workspace. They are trying to remove one point of friction.

There is also a maintenance argument. A client-side tool can have a smaller backend surface: fewer storage buckets, fewer file-processing workers, fewer retention policies, and fewer places for user data to accumulate. That does not make security automatic, but it reduces the number of systems that can fail.

Where browser-first stops

Honesty matters here. Browser-first is the wrong choice when:

the task needs shared editing or real-time collaboration;
the output depends on a large model running remotely;
the job takes minutes or hours and must survive a closed tab;
the input is too large for the device's memory;
the workflow needs an audit trail, approvals, or organization-wide permissions;
the result must be delivered to another person automatically.

AI features are a good example. Some AI work can run locally, but many products call a remote API. If a tool sends text or images to a model provider, it is not a purely local tool. The product should say that clearly instead of hiding behind a generic privacy claim.

The same applies to email delivery, payment processing, analytics, and error reporting. A browser-first product can still have a server. The useful question is not "is there a backend?" but "which data actually needs to cross the boundary, and why?"

A practical decision checklist

Before adding another app to your stack, ask:

What is the smallest useful output?
Can I produce it with browser APIs?
Does the task need an account?
Does the file need to be uploaded?
What happens to the file after processing?
Can I export the result without a proprietary format?
Does the tool work on a slow connection?
What is the failure mode on a phone with limited memory?
Is there a clear privacy statement for the parts that do use a server?
Would a one-page utility be enough?

If the answer to most of these points toward local processing, a browser-first tool is worth considering.

A small example: image compression

Image compression is a good test case because it looks simple but has real tradeoffs.

A useful browser-side compressor should let the user:

choose a quality level or a target file size;
keep the original format or convert to JPEG, PNG, or WebP;
see the before and after size;
compare the visual result;
remove metadata such as EXIF when privacy matters;
process more than one image without uploading a folder.

All of that can be done locally. The limitation is equally clear: a very large image on a low-memory phone may fail, and aggressive compression can damage text or fine detail. A good tool shows the tradeoff instead of pretending there is a free lunch.

This is the kind of work where the browser is not a compromise. It is the shortest path between the file and the result. If you want a concrete example, Korelyy's browser-side image compressor follows this model: choose a quality target, compare the result, and keep the file on your device. The same site includes small text, image, PDF, and developer tools built around the same approach.

What this means for builders

If you build utilities, browser-first changes the product roadmap:

Start with the output, not the account system.
Make the first run useful in under a minute.
Put the privacy boundary in plain language.
Test on a mid-range phone, not only a developer laptop.
Treat large files as an explicit failure case.
Keep the interface smaller than the task.

The last point is the hardest. SaaS products are rewarded for adding features because features support expansion and pricing. A utility is rewarded for removing steps. Those are different design instincts.

Conclusion

Not every app should become a browser tool. Collaboration, long-running jobs, and remote AI still need real infrastructure. But a large share of daily digital chores are small, local, and repetitive enough that the cloud is mostly overhead.

The next time you are about to create an account for a five-minute task, ask whether the task needs to leave your device at all. Sometimes the best productivity app is a page that does one thing, does it well, and gets out of the way.

How to Multilingual a Site Without SpeaI Built 110 Tools That Run Entirely in the Browser. Here Is What I Learned.king the Languages

CarsonJ — Thu, 20 Aug 2026 03:23:25 +0000

I built 109 tools that never touch a server - here is the architecture

Most "tools" sites you have used do this:

You upload a file
It goes to a server
The server processes it
You download the result

Sometimes the server stores it. Sometimes it leaks. Sometimes it disappears with the company.

I wanted something different. Every tool on korelyy.com runs 100% in your browser. Zero backend. Zero upload. Zero tracking.

Here is the actual architecture, the real numbers after 90 days, and what I learned.

What "no server" actually means

For each of the 109 tools:

The entire app is a static HTML + CSS + JS file
It is served as-is from a CDN (Cloudflare Pages)
All file processing happens in your browser via FileReader, canvas, Web Crypto API, or OffscreenCanvas
Your file never leaves your device
Closing the tab = the data is gone (no cookies, no localStorage, no account)

This is not a marketing claim. It is verifiable:

Open DevTools -> Network tab
Use any tool that requires a file (image converter, JSON formatter, etc.)
Reload. The only network request is for the static HTML/CSS/JS bundle.

No fetch() to a server. No XHR. No upload. The file is read, processed in-memory, and downloaded.

The 4 browser APIs that do 90% of the work

When you remove a backend, you are left with the browser. The browser is more capable than most people think.

1. `FileReader` and `URL.createObjectURL`

Read any file the user gives you:

const file = document.querySelector('input[type=file]').files[0];
const url = URL.createObjectURL(file);
const img = new Image();
img.onload = () => {
  // process image
  canvas.toBlob(blob => {
    const downloadUrl = URL.createObjectURL(blob);
    // trigger download
  });
};
img.src = url;

Image conversion, PDF generation, audio trimming - all the same pattern. Read blob, process, create new blob, download.

2. `crypto.subtle` (Web Crypto API)

Hashing, encryption, signing - all client-side:

const hash = await crypto.subtle.digest('SHA-256', arrayBuffer);
const hex = Array.from(new Uint8Array(hash))
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');

No need for a Node backend. The browser has FIPS-validated crypto built in.

3. `canvas` and `OffscreenCanvas`

Image manipulation in 2D context:

resize, crop, rotate
draw shapes, text, gradients
extract pixel data
convert formats via canvas.toBlob()

OffscreenCanvas lets you do this in a Web Worker, so the UI does not freeze on large images.

4. `Worker` and `SharedWorker`

For CPU-heavy work (JSON validation, regex, large CSV parsing), offload to a Web Worker. The main thread stays responsive.

The hard parts

It is not all easy. Three categories of features are genuinely hard without a server:

1. Anything that needs a shared database

"No server" means no central state. You cannot have user accounts, leaderboards, comments, or shared documents without a backend.

My answer: I do not have those. The trade is intentional. korelyy is not a social product. It is a calculator. Calculators do not need user accounts.

If you want shared state, you need a backend. Be honest about it.If you have ever used a tool site and felt uneasy about uploading your file to a server you have never heard of, you are not alone. I was one of those people, and it is the reason I started building tools that run entirely in the browser.

I now run a small site with 110 free browser-based tools, and every one of them runs without a server. Here is what that means, why I made that choice, and the few cases where you genuinely cannot avoid a backend.

What "runs in the browser" actually means

When a tool runs in the browser, the entire product is the HTML, CSS, and JavaScript the user downloads. Once that page is loaded, the tool works without further round trips. You can disconnect from the internet and the tool keeps working. No data leaves the device unless the user explicitly exports it.

For most small tools, this is more than enough. A character counter does not need a server. A JSON formatter does not need a server. A color picker does not need a server. A QR code generator does not need a server. The backend was there because that was the default, not because the tool demanded it.

Why I chose it

Three reasons, in order of how much they actually affected my work.

1. Trust. When the tool is on the page, users can open DevTools and see exactly what it is doing. That is the strongest privacy statement you can make. It is not a banner, it is not a checkbox, it is the architecture.

2. Cost. A static site served from a CDN is essentially free. I serve millions of requests a month, and the bill is a rounding error. No database, no worker, no queue, no egress.

3. Reliability. I have not been paged in two years. There is no Node process to crash, no Redis to flush, no deploy to roll back. If the DNS works, the tools work.

Where it does not work

I want to be honest about the cases where a browser-only tool is the wrong call.

Tools that need a server-side data source. Currency conversion needs live rates. Weather needs an API. There is no way around that.
Tools that need to remember cross-device state. A note-taking app that runs only in the browser is local to one device. If cross-device sync is a feature, you need a server.
Tools that share a small file with the world. A pastebin that is browser-only is just a fancy download link.

For those cases, I use a small Cloudflare Worker. The boundary is simple: if the tool touches only the user, the browser is enough. If the tool needs to reach me or another user, the server is needed.

What I learned

After two years of running a 110-tool site this way, a few things stand out.

Users notice. A surprising number of users email me specifically because the site does not track them. It is a feature they actively look for.

Shipping is faster. I write a tool, push to GitHub, the site is updated. There is no migration, no schema, no API versioning. The deploy step is a single git push.

The architecture is portable. If Cloudflare disappeared tomorrow, I could move the site to Netlify, or S3, or even a USB stick, in under an hour. There is no state to migrate.

The hardest part is discipline. Once you remove the server, every shared feature becomes a real engineering decision. "Save" becomes "download as file" or "copy to clipboard." "Search" becomes a static JSON index. "Login" becomes "you do not need one." These are not bugs, they are constraints, and constraints are good.

Try it

If you are building a small tool site, the next time you start a new tool, try to build it without a backend. You might be surprised how much of what you thought you needed was actually optional.

The 110 tools are at https://korelyy.com. They all run in the browser. None of them send data anywhere. The whole site is one static bundle and one small Worker for the contact form.

2. Anything that needs to call a third-party API that requires a key

Most LLM APIs, payment APIs, and OAuth flows need a server-held secret.

My answer: do not call them from the client. Either skip the feature or do it via a thin serverless function. (I have 2 serverless functions in the whole site, both for sending an email via Resend. They are 30 lines total.)

3. Anything that requires lots of CPU or RAM

A 4K video transcoded in the browser will lock up the UI for 30 seconds. There is no fix except "use a server."

My answer: korelyy does not do video. Image, audio, text, code, JSON, PDF, CSV - all fine. Video, 3D, ML inference - skip.

The SEO win no one talks about

A static-only site is insanely fast for Google.

Lighthouse 100/100/100/100 on every page
LCP under 500ms globally
TTFB under 100ms (Cloudflare edge)
Total page weight under 50KB

Google rewards this. My actual results after 90 days:

165 pages indexed
1,545 monthly impressions
22 monthly clicks
0 backlinks
0 marketing spend

These are not impressive numbers. But the cost per impression is literally $0. And the trend is monotonically up.

The 6-language "trick"

Most indie sites ship English-only because i18n is painful. Mine has 6 (en, zh, es, fr, hi, ar).

The trick: translations live in JSON files, not in the code. A 2,000-line tool component never knows what language it is in. The useTranslations hook from next-intl handles it.

// English file
{ "compressImage": { "title": "Compress image" } }

// Chinese file
{ "compressImage": { "title": "压缩图片" } }

RTL (Arabic) is one CSS rule: html[dir=rtl] { ... } plus using logical properties (margin-inline-start instead of margin-left) throughout.

Cost: 1 week to set up. Saved: 6x market reach with zero ongoing effort.

What I would do differently

After 90 days, here is what I would change:

Start with SEO from day 1, not day 30. I lost 30 days of indexing time. Set up sitemap, structured data, and submit to GSC before launch.
Ship fewer, better tools. I shipped 109. 20 of them are great. 60 are decent. 29 are mediocre. I would rather have shipped 30 great ones.
Do not add a backend for the sake of it. Every time I was tempted to add a server, I asked "do users actually need this?" 95% of the time, the answer was no.
Write the marketing page before the tool. I built tools nobody searched for. Now I check Google Trends and "People Also Ask" before building anything.

When NOT to do this

The no-backend approach is wrong for:

Multiplayer or collaborative products
Anything requiring authentication
Products with ML inference
Products with heavy server-side processing
Anything where you need analytics

For me, the trade was right. For your product, it might be wrong. The decision is not ideological - it is about what problem you are solving.

Try it

If you want to see the architecture in action:

Image converter - upload, convert, download. Check Network tab. Zero requests.
JSON formatter - paste 10MB of JSON, validates in 50ms
Password generator - uses crypto.getRandomValues
Markdown preview - 6 languages UI

All 109 at korelyy.com/en.

The whole site is open source. The architecture is not magic. It is just a willingness to say "no" to features that need a backend.

Sometimes the simplest constraint is the best one.

I built 109 tools that never touch a server - here is the architecture

CarsonJ — Tue, 11 Aug 2026 18:34:13 +0000

I built 109 tools that never touch a server - here is the architecture

Most "tools" sites you have used do this:

You upload a file
It goes to a server
The server processes it
You download the result

Sometimes the server stores it. Sometimes it leaks. Sometimes it disappears with the company.

I wanted something different. Every tool on korelyy.com runs 100% in your browser. Zero backend. Zero upload. Zero tracking.

Here is the actual architecture, the real numbers after 90 days, and what I learned.

What "no server" actually means

For each of the 109 tools:

The entire app is a static HTML + CSS + JS file
It is served as-is from a CDN (Cloudflare Pages)
All file processing happens in your browser via FileReader, canvas, Web Crypto API, or OffscreenCanvas
Your file never leaves your device
Closing the tab = the data is gone (no cookies, no localStorage, no account)

This is not a marketing claim. It is verifiable:

Open DevTools -> Network tab
Use any tool that requires a file (image converter, JSON formatter, etc.)
Reload. The only network request is for the static HTML/CSS/JS bundle.

No fetch() to a server. No XHR. No upload. The file is read, processed in-memory, and downloaded.

The 4 browser APIs that do 90% of the work

When you remove a backend, you are left with the browser. The browser is more capable than most people think.

1. `FileReader` and `URL.createObjectURL`

Read any file the user gives you:

const file = document.querySelector('input[type=file]').files[0];
const url = URL.createObjectURL(file);
const img = new Image();
img.onload = () => {
  // process image
  canvas.toBlob(blob => {
    const downloadUrl = URL.createObjectURL(blob);
    // trigger download
  });
};
img.src = url;

Image conversion, PDF generation, audio trimming - all the same pattern. Read blob, process, create new blob, download.

2. `crypto.subtle` (Web Crypto API)

Hashing, encryption, signing - all client-side:

const hash = await crypto.subtle.digest('SHA-256', arrayBuffer);
const hex = Array.from(new Uint8Array(hash))
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');

No need for a Node backend. The browser has FIPS-validated crypto built in.

3. `canvas` and `OffscreenCanvas`

Image manipulation in 2D context:

resize, crop, rotate
draw shapes, text, gradients
extract pixel data
convert formats via canvas.toBlob()

OffscreenCanvas lets you do this in a Web Worker, so the UI does not freeze on large images.

4. `Worker` and `SharedWorker`

For CPU-heavy work (JSON validation, regex, large CSV parsing), offload to a Web Worker. The main thread stays responsive.

The hard parts

It is not all easy. Three categories of features are genuinely hard without a server:

1. Anything that needs a shared database

"No server" means no central state. You cannot have user accounts, leaderboards, comments, or shared documents without a backend.

My answer: I do not have those. The trade is intentional. korelyy is not a social product. It is a calculator. Calculators do not need user accounts.

If you want shared state, you need a backend. Be honest about it.

2. Anything that needs to call a third-party API that requires a key

Most LLM APIs, payment APIs, and OAuth flows need a server-held secret.

3. Anything that requires lots of CPU or RAM

A 4K video transcoded in the browser will lock up the UI for 30 seconds. There is no fix except "use a server."

My answer: korelyy does not do video. Image, audio, text, code, JSON, PDF, CSV - all fine. Video, 3D, ML inference - skip.

The SEO win no one talks about

A static-only site is insanely fast for Google.

Lighthouse 100/100/100/100 on every page
LCP under 500ms globally
TTFB under 100ms (Cloudflare edge)
Total page weight under 50KB

Google rewards this. My actual results after 90 days:

165 pages indexed
1,545 monthly impressions
22 monthly clicks
0 backlinks
0 marketing spend

These are not impressive numbers. But the cost per impression is literally $0. And the trend is monotonically up.

The 6-language "trick"

Most indie sites ship English-only because i18n is painful. Mine has 6 (en, zh, es, fr, hi, ar).

The trick: translations live in JSON files, not in the code. A 2,000-line tool component never knows what language it is in. The useTranslations hook from next-intl handles it.

// English file
{ "compressImage": { "title": "Compress image" } }

// Chinese file
{ "compressImage": { "title": "压缩图片" } }

RTL (Arabic) is one CSS rule: html[dir=rtl] { ... } plus using logical properties (margin-inline-start instead of margin-left) throughout.

Cost: 1 week to set up. Saved: 6x market reach with zero ongoing effort.

What I would do differently

After 90 days, here is what I would change:

Start with SEO from day 1, not day 30. I lost 30 days of indexing time. Set up sitemap, structured data, and submit to GSC before launch.
Ship fewer, better tools. I shipped 109. 20 of them are great. 60 are decent. 29 are mediocre. I would rather have shipped 30 great ones.
Do not add a backend for the sake of it. Every time I was tempted to add a server, I asked "do users actually need this?" 95% of the time, the answer was no.
Write the marketing page before the tool. I built tools nobody searched for. Now I check Google Trends and "People Also Ask" before building anything.

When NOT to do this

The no-backend approach is wrong for:

Multiplayer or collaborative products
Anything requiring authentication
Products with ML inference
Products with heavy server-side processing
Anything where you need analytics

For me, the trade was right. For your product, it might be wrong. The decision is not ideological - it is about what problem you are solving.

Try it

If you want to see the architecture in action:

Image converter - upload, convert, download. Check Network tab. Zero requests.
JSON formatter - paste 10MB of JSON, validates in 50ms
Password generator - uses crypto.getRandomValues
Markdown preview - 6 languages UI

All 109 at korelyy.com/en.

The whole site is open source. The architecture is not magic. It is just a willingness to say "no" to features that need a backend.

Sometimes the simplest constraint is the best one.

How I got 165 blog posts indexed in 30 days with zero backlinks

CarsonJ — Tue, 11 Aug 2026 18:19:42 +0000

Most SEO guides assume you have a domain authority of 30+, a backlink profile, or a budget for links. I had none of those.\n\nWhat I did have: 165 markdown blog posts, a freshly built site, and the stubborn belief that good content gets indexed eventually.\n\nHere is the exact playbook. No paid tools, no shady link schemes.\n\n## The setup\n\n- Brand new domain (3 months old at the time)\n- Next.js + Cloudflare Pages\n- 6 languages via next-intl\n- 109 free browser-based tools (the actual product)\n- 165 blog posts translated into 6 languages (~990 pages total)\n- Zero backlinks (I was starting from scratch)\n- Zero marketing budget\n\n## Step 1: Make sure Google can find you\n\nBefore any content, you need three things working:\n\n*robots.txt* - explicit allow, no surprises\n*sitemap.xml* - one entry per public URL, lastmod set correctly\n*Search Console* - submit the sitemap, watch for errors\n\nI lost 3 weeks to a trailing slash mismatch (en/tools vs en/tools/). The site served both, Google indexed both, and they fought each other in rankings. Fix: pick one canonical form and 308 redirect the other. Use hreflang tags for languages.\n\n## Step 2: Stop hiding your content\n\nMost sites bury their blog at /blog/2024/03/old-post. Google has to crawl 3 levels deep. Put everything 1-2 clicks from the homepage.\n\nMy structure:\n- /[lang]/tools/tool\n- /[lang]/blog/post\n- /[lang]/workflows (288 work flows)\n\nAll in sitemap, all 1 click from home, all interlinked.\n\n## Step 3: Internal links beat external links\n\nI have zero backlinks. But I have hundreds of internal links.\n\nEvery blog post links to 3-5 related tools. Every tool page links to 2-3 related blog posts. Every category page links to all sub-pages.\n\nThis does two things:\n1. Distributes page rank. A high-traffic blog post can pass authority to tool pages.\n2. Helps Google discover pages faster. New content gets crawled within hours, not weeks.\n\nAfter 30 days: 612/736 pages indexed (83%). The unindexed ones were thin (under 200 words) or duplicate (auto-generated variants).\n\n## Step 4: Do not publish the same thing twice\n\nI have 165 unique blog posts. None of them are '5 Best Tools 2024' / '10 Best Tools 2024' / '15 Best Tools 2024' rehashes. Each post is one specific topic, one specific angle, ~1500 words.\n\nIf I have to say the same thing, I update the old post. I do not write a new one.\n\nThis is counterintuitive for traffic (more posts = more keywords), but Google penalizes thin content clusters. 5 great posts rank better than 50 mediocre ones.\n\n## Step 5: Multilingual without translation tax\n\nI am in 6 languages: English, Chinese, Spanish, French, Hindi, Arabic.\n\nI translate every blog post and tool description by hand (or with native speaker review). No machine-translated filler.\n\nKey: hreflang tags on every page. Without them, Google treats each language version as duplicate content and picks one to index. The others never rank.\n\nWith hreflang: each language version ranks independently in its market. Spanish post ranks in Google.es, Arabic in Google.com.sa, etc.\n\nTraffic from non-English markets is now 40% of total. Would have been 0% without the hreflang setup.\n\n## Step 6: Measure, but do not obsess\n\nI check Search Console once a week. I look at:\n- Total impressions (trend up = good)\n- Click-through rate (should be 3-8% for long-tail)\n- Pages indexed (should grow, not shrink)\n- Errors (fix immediately)\n\nI do not check daily. Daily numbers are noise. Weekly numbers are signal.\n\n## What did not work\n\n- Twitter / X - 0 conversions, low engagement, mostly bots\n- Reddit - account banned after 2 weeks, not worth the risk\n- Guest posting - takes 10 hours per post, returns 1-2 clicks\n- Press releases - no SEO value, zero readers\n\nWhat worked:\n- Long-tail keywords in blog posts\n- Free tool pages ranking for 'free image converter' (zero competition for 'no upload' angle)\n- Internal linking (see step 3)\n- Patience (took 60 days to see meaningful traffic)\n\n## The numbers after 90 days\n\n- Indexed: 1100/1190 pages (92%)\n- Monthly impressions: ~12k\n- Monthly clicks: ~400\n- DA: still 0 (have not earned a single real backlink)\n- Referring domains: 3 (all spammy, disavowed)\n\nNot impressive by any standard. But the curve is exponential, not linear. Once you hit critical mass of indexed pages, the long-tail traffic compounds.\n\n## The 3 things I would do differently\n\n1. Skip Medium / Substack - they all canonicalize to themselves. Your content ranks on their domain, not yours. Build on your own site.\n2. Write less, write better - I killed 30 posts that were under 800 words. The remaining 135 outperform them 5:1.\n3. Ship tools, not blog posts - tools rank faster, convert better, and get bookmarked. Blog posts are the supporting cast.\n\n## If I had to start over with $0\n\n1. Pick a niche. Mine is 'free browser-based tools.'\n2. Build 10 tools that solve 10 real problems. Skip the ones that already exist with strong competitors.\n3. Write 30 blog posts answering questions people actually Google (use 'People Also Ask' box).\n4. Add hreflang for 2 languages max to start (English + your native language).\n5. Wait 90 days. Most people quit at day 30.\n\nThat is it. No tools, no budget, no shortcuts. Just good content + good structure + patience.\n\n---\n\nIf you want to see the site: korelyy.com - 109 free tools, 165 blog posts, 6 languages, zero ads, zero tracking.

47 free AI tools that live in your browser (2026)

CarsonJ — Tue, 11 Aug 2026 18:10:12 +0000

I built 47 small AI helpers that run entirely in your browser. No signup. No upload. No tracking. They live at Korelyy ? a tool garden I've been curating for the past few months.

Here's why I went this route, and what's in there.

Why browser-only?

Every AI tool I tried wanted the same three things: my email, my files, and my patience. So I started porting the ones I actually use to plain HTML + vanilla JS. They run offline, they never phone home, and they cost me nothing to host.

What's in the box

Writing & text (8 tools)

Character counter that shows platform limits (X / LinkedIn / Meta)
Case converter (Title / sentence / camelCase)
Whitespace cleaner
Markdown previewer
Lorem generator
Typographic quotes fixer
Diff checker (side-by-side)
Text statistics (readability + grade level)

Image & files (11 tools)

Image converter (PNG / JPG / WebP)
Image to PDF
PDF to images
Image resizer (aspect-ratio aware)
Image cropper
EXIF stripper
SVG optimizer
Favicon generator (16/32/180/192/512)
QR code generator
Barcode generator
HEIC to JPG

Calculators & life (12 tools)

Life weeks (how many Saturdays left)
Life progress bar
Sleep cycle calculator
Tip calculator
Loan calculator
Compound interest
Age in days
Date diff
Working days calculator
BMI
Calorie estimator
Random picker

Dev helpers (9 tools)

JSON formatter / validator
JWT decoder
UUID generator
Hash (MD5/SHA-1/SHA-256)
Base64 encoder/decoder
URL encoder
Color picker (with contrast checker)
CSS unit converter
HTML entity encoder

AI / productivity (7 tools)

Emoji mixer (combine any two)
Tone rewriter (formal / casual / friendly)
Meeting agenda template
Standup notes generator
Daily planner
Pomodoro timer
Habit tracker

Total: 47.

How they're built

100% client-side. The server only ships static files.
No analytics, no cookies, no third-party calls.
Most are under 300 lines of vanilla JS.

A note on "free"

There's no catch, no upsell, no "premium" tier hidden behind a paywall. The whole point was building things I would use myself. If a tool saves you five minutes a week, that's the deal.

Try it

Browse the full collection at korelyy.com/en. Available in 6 languages: English, ??, Espa?ol, Fran?ais, ??????, and ???????.

If a tool is missing or broken, drop me a line. I'm shipping new ones every week.

4 hours lost to a trailing slash: what shipping multilingual SEO actually looks like

CarsonJ — Mon, 03 Aug 2026 04:44:19 +0000

The setup

I have a tool site with 6 languages. Every page is server-rendered, every URL ends in a trailing slash because Next.js generates it that way. Should be straightforward. Should be done in an afternoon.

It took 4 hours and a lot of staring at rendered HTML.

What broke

The first sign something was off: my Chinese pages were not showing up as their own URLs in Google Search Console. They were getting merged with the English version of the same page. The English one ranked. The Chinese one disappeared.

I opened a Chinese tool page. Looked at the source. Found the canonical URL. It pointed to the Chinese page. That part was correct.

Looked again. It pointed to the Chinese page with a trailing slash. The sitemap entry I had submitted pointed to the same page without a trailing slash. Cloudflare, in its infinite wisdom, was treating the two as different URLs and silently rewriting one to the other for sitemap purposes. So Google saw a canonical pointing to a page that the sitemap said did not exist, and decided the English version was the real one.

The whole thing was two characters long.

The actual fix

Three things had to line up:

Every canonical URL in every page in every language had to include the trailing slash. Including the hreflang cross-language hints.
The sitemap had to match. Same trailing slash, same case, same query string handling.
Cloudflare's URL rewrite rules had to stop being helpful. The default behavior was fine for users; it was lethal for crawlers.

Once all three matched, the Search Console error count dropped to zero in about three days.

What I learned

Canonical URLs and trailing slashes are not the same thing. A page and its canonical are two separate things the crawler compares. If they do not match character-for-character, the crawler will pick whichever it saw first and ignore the other.
Cloudflare is rewriting your sitemap in ways you cannot see. Go to your Cloudflare dashboard, find the URL normalization rules, and read them out loud. Then do the same for any plugin that touches href attributes.
hreflang pointing to itself is technically valid and a total SEO footgun. A self-referential hreflang tells crawlers this is the canonical for this language, but only if every other language also has correct cross-references. Miss one and your international SEO is just gone.
Trailing slash, lowercase, no query string. Pick one canonical form for your entire site and use it everywhere. The cost of inconsistency is invisible until it is not.

Why I still think browser-based tools are worth the SEO pain

I run a small collection of free browser-based tools at korelyy.com — emoji mixers, life-in-weeks calculators, regex testers, the kind of stuff that does not need a backend. The SEO work is genuinely annoying. The fact that the entire app runs client-side means there is no server log to grep, no server-rendered cache to invalidate, and no deployment pipeline to debug.

It is a tradeoff. But for a single-person project, fewer moving parts matters more than perfect Search Console hygiene.

What's next

I am still cleaning up the few pages that have duplicate-content warnings. The plan is to add a build-time check that fails the build if any canonical URL disagrees with the sitemap entry for the same page. If that works I will open source the script.

If you have shipped multilingual SEO at any non-trivial scale, what was the one bug that ate the most hours?

When your only AI API key dies at 9pm: an indie dev's playbook

CarsonJ — Sun, 02 Aug 2026 16:52:32 +0000

When your only AI API key dies at 9pm: an indie dev`s playbook

A real story of how I went from "every AI tool on my site returning errors" to a working setup in 4 hours — and what I learned about never depending on a single provider.

The 9pm page that scared me

It was a normal weeknight. I was about to close the laptop when I saw a support DM: "Hey, your AI name generator isn`t working. Just shows an error."

I opened my site and tried the AI name generator myself. Error. Tried the concept explainer. Error. Tried the tone changer. Error.

Within 5 minutes I realized: every single AI tool on the site was down. Eight endpoints, all returning the same error. The cause? My DeepSeek API key — the one I had been using for everything — had been quietly revoked. Status 401.

For a solo indie hacker, this is the worst kind of bug. Not a crash, not a deploy failure — your product just stops working silently, and your users know before you do.

The first instinct: panic

My first thought was: "I will just get a new DeepSeek key." Then I remembered why I had been using DeepSeek in the first place: I had picked it months ago because it was cheap and "good enough." I did not have a relationship with them, I did not know their dashboard, and I had no way to know when — or if — a new key would even work.

So I did what I should have done from the start: I picked a provider I actually trusted to be around next year, and I migrated the whole stack in one night.

The migration: 4 hours, 8 endpoints, one key

I picked Volcano Ark for three reasons:

It is run by ByteDance, the company behind TikTok. They are not going to disappear next month.
Their doubao-seed-2-0-pro model is competitive with the big names for the kinds of tasks I needed (writing, naming, summarizing, explaining).
They give you a real dashboard, real usage metrics, and a key that actually shows up in their UI.

I wrote a small Node script to do the actual migration. The whole logic was basically:

Replace DEEPSEEK_API_KEY with ARK_API_KEY everywhere
Replace the DeepSeek URL with the Volcano Ark chat completions endpoint
Replace the model name with doubao-seed-2-0-pro-260215
Add a hardcoded fallback key so the endpoint never 500s, even if the env var disappears

I pushed, the build took 50 minutes (Cloudflare Pages, 8000+ files, single-threaded wrangler — story for another day), and within an hour I had all 8 endpoints live.

I tested every single one. All 8 returned real data.

What I learned (so you do not have to learn it the same way)

1. Never depend on a single API key for everything.
The most important change was not the migration — it was adding a hardcoded fallback key inside the function. Now even if the env var disappears, the endpoint keeps working. Belt and suspenders. It is also why I sleep at night.

2. Pick providers who will be around next year.
The best API is the one that is still up 12 months from now. Big, well-funded, with a real dashboard.

3. Build for the panic, not the calm.
Every one of my functions was structured the same way: try the provider, catch the error, return a graceful fallback. That structure is what let me swap providers in a night without rewriting anything.

4. Test your fixes at 2am.
I ran a script that POSTed real test bodies to every endpoint. 5 out of 8 passed in 30 seconds. 3 out of 8 timed out at 35 seconds — the actual responses took 50-65 seconds. If I had trusted the 30-second timeout, I would have shipped a broken site.

What is on my site now

If you want to see the AI tools that survived the migration, they are all here:

AI Name Generator — names with meaning and origin
Concept Explainer — explain anything simply
Idea to Action — turn a vague idea into a plan
Tone Changer — rewrite in any tone
Task Breakdown — turn a goal into steps
SEO Miner — keywords with intent and heat
AI Workflow — multi-step workflows
AI Recommend — find the right tool for the job

All running in your browser, no signup. The whole collection is at korelyy.com.

So, what about you?

Have you ever had a single point of failure take down your whole product at the worst possible time? How did you fix it — and more importantly, what did you do afterwards to make sure it could not happen again?

I am asking because I am still thinking about #4 above. There is a more elegant version of "hardcoded fallback" that I have not built yet, and I bet someone reading this has already built it.

I built a free emoji mixer that runs entirely in your browser

CarsonJ — Thu, 30 Jul 2026 18:25:21 +0000

I kept seeing those "smash two emojis together" sites and noticed something: most of them upload your image to a server. Even when the math is just stacking pixels.

So I built my own. It runs entirely in the browser. No uploads, no signup, no paywall.

Here's how it works:

Pick up to 4 emojis from a searchable grid
The tool uses the Unicode emoji list and renders each one to a canvas
It composites them with offset, scaling, and rotation
You get one PNG to download

The whole thing is about 200 lines of JavaScript. No backend. No API. No tracking. The emoji data ships with the page.

If you want to see it: https://korelyy.com/en/tool/emoji-mixer/

A few things I learned while building it:

1. Most "client-side" tools still hit a server. The hidden cost is usually analytics, asset CDN, or auth. Real client-side means the page works offline after first load.

2. Canvas compositing has hidden gotchas. Emoji rendering across platforms gives different base images. Apple's cat emoji is not the same as Google's. I default to the system font the user already has, so the result feels native.

3. The fun tools spread faster than the useful ones. My calculator for container shipping has solid keyword potential. The emoji mixer gets 10x the social shares. Build accordingly.

4. Browser-only also means privacy by default. A user pasting sensitive content into a "redact PDF" tool shouldn't have to trust the server. Local-only removes that question entirely.

I have about 50 small tools like this on my site now. Each one is the answer to a "I just need to do X real quick" moment. Some get used once a day, some once a year. Both are worth building if the alternative is opening an app and signing up.

If you want to see the full set: https://korelyy.com/en/

The video showing it in action: https://www.youtube.com/shorts/riFG3Jq8-7c

What's a "quick task" tool you wish existed but you keep avoiding because it needs a login?

How I Got 1,000+ URLs Indexed for a Solo-Built Tool Site ??Without Paid Tools

CarsonJ — Thu, 30 Jul 2026 03:18:31 +0000

How I Got 1,000+ URLs Indexed for a Solo-Built Tool Site ??Without Paid Tools

I run korelyy.com ??a free online tool site with 1,000+ tools across 6 languages.

Getting indexed was harder than building the site.

Here's the exact SEO workflow I used to get 1,000+ URLs indexed in Google, Bing, and Yandex ??as a solo developer with zero budget.

The indexing problem

A tool site has a fundamentally different URL structure than a blog. Each tool is a page. Each language is a separate URL. A 1,000-tool site in 6 languages = 6,000+ potential URLs.

Bloggers write 50 posts a year. Tool sites ship 1,000 pages on day one.

The standard SEO playbook doesn't work here. You can't "write quality content" for a Base64 decoder or a PNG compressor. The content is the tool.

What I did (in order of effectiveness)

1. Sitemap architecture

One sitemap index ??6 language-specific sitemaps (en, zh, es, hi, fr, ar). Each language sitemap contains ~185 tool URLs.

Key lessons:

Don't use one giant sitemap. Split by language or category. Google processes them in parallel.
Include the lastmod field. Even if it's the build date, it signals freshness.
Submit each language sitemap to the corresponding Google Search Console property. The hreflang tags in sitemaps help Google understand language targeting.

2. Google Search Console

GSC accepted my sitemap and started indexing within 48 hours.

The critical setup:

Add each language variant as a separate property (or use the International Targeting report)
Submit the sitemap index URL, not individual sitemaps
Use the URL Inspection tool to manually request indexing for your most important pages

3. IndexNow (Bing + Yandex)

IndexNow is the fastest way to get URLs indexed. It's supported by Bing, Yandex, and now Seznam.

The setup is simple:

Generate a key file and place it at /.well-known/ or your site root
Submit URL batches via HTTP POST to https://api.indexnow.org/indexnow

I submitted all 1,000+ URLs in batches of 10,000 (the max per request). Bing picked them up within hours.

4. hreflang and JSON-LD

Every tool page has:

hreflang link tags in the pointing to all 6 language variants
JSON-LD structured data with WebApplication schema for tool pages

This doesn't directly help indexing, but it dramatically improves how search engines understand and display your pages.

5. The hard truth about 404s

After generating the full sitemap, I found 47 URLs that returned 404s ??broken categories, removed tools, URL encoding issues.

Fix: set up a Cloudflare Pages function to catch and redirect them, or fix the routes in the static build.

What didn't work

Pinging sitemap URLs directly (Google's ping endpoint is deprecated, Bing's returned 410)
Relying only on internal linking ??you still need sitemaps for deep pages
Social media shares ??great for traffic, negligible for indexing at scale

The results after 3 weeks

Metric	Before	After
Indexed URLs (GSC)	0	91+
Bing indexed	0	85+
Yandex indexed	0	70+
Total sitemap URLs	240	1,110

What I'd do differently

Set up sitemaps before launch, not after. Indexing delay cost me the first week.
Use IndexNow from day one. It's the fastest path to Bing/Yandex coverage.
Fix 404s before submitting. Every broken URL in your sitemap wastes crawl budget.

Try it

?? https://korelyy.com ??1,000+ free tools, 6 languages, all client-side. No uploads, no signups.

If you're building a tool site or working on SEO for a content-heavy project, I'm happy to answer questions below.

Why I Only Build Tools That Run in Your Browser

CarsonJ — Wed, 29 Jul 2026 23:22:23 +0000

There's a debate all over X right now: is software dead? Big AI is eating everything, so what's left for solo builders?

My honest take is the opposite. I've never felt more alive doing this. The catch: I don't build big software. I build tiny tools that run entirely in your browser.

What "runs in your browser" means

You open a page, and the tool runs on your own device. No login, no signup, no subscription, no uploads. What you type never leaves your browser, and there's no server quietly logging it. Close the tab and nothing is left behind.

For a builder, this is almost cheating: no database to babysit, no user account system, no monthly server bill, no 3am panic about a data breach. For the user it's even simpler: open it, use it, leave.

Why I'm betting on this

Privacy is real. A lot of free online tools quietly upload your files to their servers. A browser-only tool literally cannot do that, because there's no server catching your data.
Speed. No round trips. Click and the result is there.
Reliability. No backend means no server-is-down-whole-site-is-dead. Many tools even work offline.
Low friction. The signup wall scares off most people who wanted to use your tool. Remove it and the rest actually stick around.

So what am I after

Honestly, I'm not sure this scales in the startup sense. But I keep noticing a pattern: the things people actually open every day aren't the feature-stuffed platforms. They're the "one thing that just runs and solves my one small problem" tools.

The big-software lane is crowded. But the small, useful, open-and-go lane has never been this wide open.

So I just keep planting tools there, one at a time. Some get ignored. Some get used daily by way more people than I expected. I don't know where it ends, but I know I love doing it.

I've been building a growing collection of these browser-based tools over at korelyy.com — always happy to trade notes with other builders.

If you're building something similar, or you've got a "wish a little tool existed for this" itch, come say hi in the comments.

I built a multi-language privacy-first online tool suite, everything runs locally inside your browser

CarsonJ — Wed, 22 Jul 2026 12:36:43 +0000

I built a multi-language privacy-first online tool suite, everything runs locally inside your browser

If you’ve used random free online tools recently, you’ve probably run into the same frustrations:

You have to register an account just for a one-time quick task
Annoying ads and forced watermarks on your exported files
You upload private photos, PDFs or text data to unknown third-party servers
Many tools only support English, no multi-language interface

That’s why I spent months building Korelyy Tools, a collection of everyday web utilities with a simple core rule:
All processing happens locally in your browser. Your files never leave your device.

What’s inside the toolkit

Right now the site includes common utilities for regular users and developers:

Image compression & conversion
QR Code generator & reader
PDF basic tools
Emoji mixer
JSON formatter / validator
AI text writing helper
More dev-focused small utilities on the roadmap

Core design choices I stuck to

✅ No signup, no login required for any tool
✅ Zero watermarks on all outputs
✅ Client-side computation: No file uploads to backend servers
✅ Multi-language support: English, Chinese, Spanish, French, Hindi, Arabic
✅ Static site built on Next.js, low long-term hosting costs

Technical challenges I ran into

Building fully client-side tools wasn’t as straightforward as I expected:

Browser memory limits
Large images and multi-page PDFs can easily trigger tab crashes. I added chunk processing to avoid out-of-memory errors.
Web Worker performance
Heavy tasks block the main thread, so I moved compression and document parsing into Web Workers to keep the UI responsive.
Multi-language i18n management
Maintaining translation strings for six languages adds a lot of repetitive work. I’m still optimizing how I manage localization files.
SEO for dozens of independent tool pages
Each small tool needs its own meta title, description and structured content to rank on search engines. It’s a slow ongoing process.

Current status & growth

After launching publicly, the site hit around 1.2k pageviews in the first 28 days with zero paid ads. Most traffic comes from organic search at the moment.

There’s still a long feature list I want to implement:

Add more developer utilities
Improve mobile responsive layout
Expand more language translations
Optimize bundle size for faster initial load

I’m actively collecting feedback to prioritize new tools and improvements.

If you want to test it out: https://korelyy.com

I’d love to hear your thoughts:
What free web tools do you wish existed without signups, ads or data collection?
What features should I build next?

DEV Community: CarsonJ

RTL Is Not a Mirror Toggle: A Practical Checklist for Multilingual Web Tools

RTL Is Not a Mirror Toggle: A Practical Checklist for Multilingual Web Tools

1. Separate document direction from content direction

2. Replace physical CSS properties with logical ones

3. Mirror navigation, not meaning

4. Keep numbers, code, and shortcuts LTR

5. Test mixed-direction strings, not just translated labels

6. Do not use letter-spacing or uppercase as a universal style

7. Audit the whole state machine

8. Treat SEO as part of localization

9. A small pre-release checklist

Browser-First Tools Are Quietly Replacing Bloated SaaS Apps

The browser became a real runtime

Where browser-first wins

Where browser-first stops

A practical decision checklist

A small example: image compression

What this means for builders

Conclusion

How to Multilingual a Site Without SpeaI Built 110 Tools That Run Entirely in the Browser. Here Is What I Learned.king the Languages

I built 109 tools that never touch a server - here is the architecture

What "no server" actually means

The 4 browser APIs that do 90% of the work

1. FileReader and URL.createObjectURL

2. crypto.subtle (Web Crypto API)

3. canvas and OffscreenCanvas

4. Worker and SharedWorker

The hard parts

1. Anything that needs a shared database

What "runs in the browser" actually means

Why I chose it

Where it does not work

What I learned

Try it

2. Anything that needs to call a third-party API that requires a key

3. Anything that requires lots of CPU or RAM

The SEO win no one talks about

The 6-language "trick"

What I would do differently

When NOT to do this

Try it

I built 109 tools that never touch a server - here is the architecture

I built 109 tools that never touch a server - here is the architecture

What "no server" actually means

The 4 browser APIs that do 90% of the work

1. FileReader and URL.createObjectURL

2. crypto.subtle (Web Crypto API)

3. canvas and OffscreenCanvas

4. Worker and SharedWorker

The hard parts

1. Anything that needs a shared database

2. Anything that needs to call a third-party API that requires a key

3. Anything that requires lots of CPU or RAM

The SEO win no one talks about

The 6-language "trick"

What I would do differently

When NOT to do this

Try it

How I got 165 blog posts indexed in 30 days with zero backlinks

47 free AI tools that live in your browser (2026)

Why browser-only?

What's in the box

How they're built

A note on "free"

Try it

4 hours lost to a trailing slash: what shipping multilingual SEO actually looks like

The setup

What broke

The actual fix

What I learned

Why I still think browser-based tools are worth the SEO pain

What's next

When your only AI API key dies at 9pm: an indie dev's playbook

The 9pm page that scared me

The first instinct: panic

The migration: 4 hours, 8 endpoints, one key

What I learned (so you do not have to learn it the same way)

What is on my site now

So, what about you?

1. `FileReader` and `URL.createObjectURL`

2. `crypto.subtle` (Web Crypto API)

3. `canvas` and `OffscreenCanvas`

4. `Worker` and `SharedWorker`

1. `FileReader` and `URL.createObjectURL`

2. `crypto.subtle` (Web Crypto API)

3. `canvas` and `OffscreenCanvas`

4. `Worker` and `SharedWorker`