Why I’m doing this
I wanted a place to practice real-world front-end: routing, state, accessibility, keyboard flows, and performance. Shipping tiny, single-purpose tools forces me to learn quickly and iterate.
About Utilixy
I’m building Utilixy as a way to learn how the web actually works: performance, browser APIs, file handling, workers, and a bunch of little UX details. The tools are simple on purpose—small projects that help me explore, and (hopefully) help you get things done, fast.
Principles
- Local-first: everything runs in your browser.
- Fast: minimal clicks, snappy UIs, no bloat.
- Private: I don’t want your files—I don’t need them.
- Useful over perfect: small features, shipped often.
How it’s built
Next.js + TypeScript + Tailwind for the UI. Under the hood: browser APIs (Canvas, File, Streams), Web Workers for heavy work, and lightweight libraries where it makes sense (e.g. PDF handling, zipping, QR generation). Everything aims to be client-side only.
What runs locally?
- PDF Studio: reordering, merging, splitting, numbers, watermarks, redaction, conversions.
- QR & Wi-Fi: generate and export QR codes (PNG/SVG).
- Image tools: convert common formats right in the browser.
- Formatters & text tools: JSON/YAML/XML, regex tester (highlight, replace, split), case converter, diff, Base64, etc.
If a tool ever needs a network call (rare), I’ll call it out in the UI.
Is anything uploaded?
No—by default, files are processed locally in your browser. That’s the whole point: fast, private, disposable.
What about ads/consent?
Ads help keep the site free. If you decline personalization, you’ll still see non-personalized (contextual) ads without tracking cookies.
Can I suggest a feature?
Please do—I’m learning as I go. Bug reports, UX nitpicks, and small wins are very welcome.
Is this open-source?
Parts may be opened up as they stabilize. The goal is to keep things simple enough that you can read the code and learn from it too.
Say hello
Found a bug? Want a tool? Curious how something works?