DEV Community

Cover image for Build Your Own Browser Tools Without a Backend
J Lopes
J Lopes

Posted on Originally published at jlopes.eu

Build Your Own Browser Tools Without a Backend

Carrot, meet stick!

Once upon a time, I wanted to resize about forty screenshots. The first few search results either wanted an account before they would touch a file, or did three of them and then asked me to register for the rest.

So... What's stopping them from just doing the thing?

If you are not paying for it, you're not the customer; you're the product being sold.

blue_beetle, 2010

Resizing or converting an image can be accomplished by using browser APIs and a few bits of JavaScript, like <canvas> and toBlob. Why would the user need yet another login and be tracked for this?

I don't know... I guess I've gotten jaded about being treated as the product, when I showed up expecting to be a customer.

For a few years now, instead of relying on black-boxed services for the small things I needed in my daily routine, I ended up building a few myself. Maybe out of revolt, or just a will to understand how the gears turn to make a machine work.


You too can make tools, and I promise you'll love it

An illustration of a swiss army knife with several different design tools.

I've been building tools for myself, for years. For specific things like:

  • Colour palette generator, because I wanted to know how you get a set of colours, and how to convert them into other colour formats.
  • Word cloud generator, which turned out to be a collision-detection problem rather than a typography one.
  • Markdown and WYSIWYG converter, to find out what happens when two different editors both think they're in charge of the same document.
  • Text fragment URL generator, because the #:~:text= syntax that links straight to a phrase on a page is fiddly enough that I'd rather generate it than type it.

My stack recommendations

I tend to rely on frameworks like React, Vue, Svelte and Astro, as these arrive with routing, build steps and dev server already wired up.

Frontend stacks might seem intimidating to get into from the beginning, but the learning curve isn't as steep as you might expect, and the learnings from one apply to the rest, in one form or another. The important part is that the stack can be interchangeable after a while.

I'd avoid relying on AI to help though, as it defeats the purpose of making tools for learning. Otherwise you might as well use anyone else's tool site...


DISCLAIMER: This is not an article about me tooting my own horn. Please take it as a short manifesto.

A comic panel. Namor shouts 'Do not toot it!' as Doctor Doom answers 'Fool! Doctor Doom toots as he pleases!'

Spidey Super Stories #53


But first, my tools!

This year I decided to consolidate them in /tools. Every tool page links to its own file on GitHub, so users can see how the gears work for themselves.

For code developers and enthusiasts

  • Minify & Beautify shrinks huge swathes of code down to one line to save space, then spreads it back out to be readable. The detectCode function works out whether you're pasting HTML, CSS, JavaScript or SVG as you type, which is a tokeniser in disguise: it has to break the code into meaningful pieces before it can tell you what it's looking at.
  • Regex Tester is honestly just for me. regex101 already does the job better than I ever will, for free.
  • :nth-child Helper lets you click the elements you want and works out the CSS formulas that cover them. Finding the shortest set of formulas meant reaching for the greatest common divisor, which I did not expect from a styling tool.
  • Flexbox Generator is a playground for every CSS flexbox property at once, so you can watch what each one does instead of guessing.
  • Cron Helper translates cron values into plain English, with cRonstrue doing the parsing under the hood.
  • Icon Search covers thousands of icons. Rendering that many at once is what taught me list virtualization: only the icons currently in view exist in the page, and the rest get built as you scroll.

For designers

  • Image Resizer does bulk resizing with aspect-ratio presets, an optional crop with pan, and a zip download at the end. However many images you throw at it they go through in one pass, and the files never leave your computer. This is the tool that came out of the complaint at the top of this article.
  • Colour Palette generates random palettes for theming, and pulls them out of any image you drop in. It's the one that made me want to consolidate everything into one site, and it's where I learned that the mathematical distance between two RGB colours has nothing to do with how different they look. The pixels get converted into Lab first, a colour space built so that equal distances look equally different to the eye.
  • SVG Optimizer strips the unnecessary parts out of exported SVGs, with svgo/browser under the hood and my preferred compression settings baked in.

For text wranglers

  • Character Map needed a huge (7MB+) JSON file of every Unicode code point, and the browser's own IndexedDB to keep it between visits. Keeping it fast is the reason I wrote Understanding List Virtualization. Did I need to make this? Not really, &what; did it well already, but I wanted to learn <3
  • Markdown Editor is built on tiptap, with tiptap-markdown and marked handling the markdown side. Loved learning how to detect formatting on paste, and how to export to the clipboard.
  • Text Transformer was mostly made for fun. Who wouldn't want their own way to change text to z̸̫̖̮͇̫̯͈̥̅͋̂̉̌̉͒a̪̖͈̲͔̪̫̍͗̐̃̊̂̍̌ͅl̯͔̟̠̝͉̳̻̅́̈́̊̿̉̇̌g̖̝͈̪̖͐͌̀̿͐o̼̜̼̯͓̺̤̲͑̅͑͆̿̇̆͌?
  • Lorem Ipsum fills a page with placeholder text. It was easier to figure out than I expected, so I kept adding flavours, including corporate speak.

Web

  • UTM Builder assembles marketing campaign links. I made it to help some ex-colleagues, and anyone who ever had to write those by hand knows the pain.
  • URL Inspector is 549 lines and the only tool here that needs a server of mine. A browser can't read another site's headers directly, CORS blocks it, so a small proxy is the only way past that wall. Mine carries a per-IP rate limit, which is the exact thing I complained about at the top of this article. The difference I'd claim is that it throttles repeat fetches of one URL through an open proxy rather than metering the person using it. That is also what every metered tool would say, so take it for what it's worth.

Math

  • Unit Converter covers length, weight, temperature, speed, area, volume, pressure, storage and number bases. With some funny ones in the mix.
  • Time Converter is mostly an Intl handler. It updates Unix epoch time, ISO 8601 format and time zones in parallel, with a live clock.

General purpose

  • What Is My IP is 141 lines: it calls ipapi.co/json/ and formats the response. The browser deliberately hides your IP address from JavaScript, because any page that could read it could also fingerprint you with it. So the only way to show you your own address is to ask a server that can see where the request came from.
  • Weather joins a few services together into one worldwide weather map. It loads the mapping library Leaflet only when someone opens the tool, so it doesn't slow down every other page on the site.

The last 20%, or how I learned to love the process

I've written a bit about it before. There's a gap between a thing working and considering it ready for public. Oftentimes the last stretch of development (the last 20%) eats 80% of the development time. If you develop only for yourself, you tend to stop once it does exactly what you want. But the moment you plan to hand a tool to anyone else, there are so many other things to consider.

A pie chart split 80 percent works on my machine and 20 percent works on yours, with the smaller slice covering most of the actual work if we want to launch a tool confidently for more people

Getting from a proof-of-concept to something other people might actually want to use is such a high. Especially considering accessibility and usability. The unexpected issues and the extra requested features are opportunities for learning and experience.

Go build things!

Pick whatever service annoyed you recently with bad UX. Maybe the converter that wanted an account before it would touch your file. Make your own version, make it badly and improve on it. With AI or not (you do you, boo). Break things, read documentation when they stay broken, learn as you go. And the next time a website stops you at three free conversions, you'll know exactly how small the wizard behind that curtain really is.

Everything in my repository is free to use and peruse, and if something inspired you to make more, even if just for yourself, that's awesome!


Questions people ask me about this

Why do free online tools ask you to sign up?
The login is there to collect your email address, and sometimes the files themselves. It's a sales funnel, and that data is worth more to them than the tool costs to run. You end up being the product.

Do browser-based tools need a backend?
Mostly not. Most of the tools I developed don't touch the network at all. It depends on the goal and complexity of the tool.

What do you need to build your own browser tool?
A text editor, a browser, and somewhere to put static files. The parts that do the heavy lifting are inside every browser and are documented for free on MDN.

Can you resize images without uploading them?
Yes, and there's no reason it would need uploading. The file stays on your machine, which saves you the upload wait and keeps a copy off someone else's disk.

How do you extract a colour palette from an image in JavaScript?
Sample pixels off the decoded image rather than reading all of them, convert those samples from RGB into a perceptually uniform space like Lab, then run k-means clustering to find the dominant groups. Clustering in raw RGB is the common shortcut and it produces muddy results, because equal distances in RGB don't look equally different to a human eye.

How do you render 30,000 characters without freezing the page?
Virtualise the grid so only the visible rows exist in the DOM, and cache the dataset in IndexedDB so it isn't re-downloaded on every visit. The rendering half of this is covered in detail in Understanding List Virtualization.

Top comments (0)