home / about

Why we built GlaeKit

Small dev tasks kept costing real time — not because they were hard, but because of what stood between us and doing them.

GlaeKit started from a pattern that repeated on nearly every project: a small task would come up — decode a token, compress a PDF, convert an image, format some JSON — and the fastest fix wasn't the tool itself, it was finding a tool that would actually let us use it.

Search for almost any one of these tasks and the results are the same story on repeat: a daily usage limit that runs out mid-project, a sign-up wall asking for an email and personal details for something that should take ten seconds, or a subscription pitch for a "pro" tier gating a feature that's genuinely trivial to run. For a two-minute task, that's a completely disproportionate amount of friction.

The actual problem

None of these are hard problems from an engineering standpoint. Decoding a JWT, resizing an image, validating JSON — these can all run entirely in a browser tab, with no server round-trip and no file ever leaving your machine. The limits, sign-ups, and subscriptions that most sites put in front of them aren't there because the task is expensive to run. They're there because the site's business model needs an email address, an account, or a payment before it'll do something a few lines of client-side JavaScript could already do for free.

That mismatch — trivial task, disproportionate gate — is what GlaeKit is built to remove.

What GlaeKit actually is

A growing set of browser-based tools — PDF editing, image conversion, JSON/YAML/CSV formatting, encoding, hashing, and more — built to run entirely as client-side JavaScript. Your file or text is read, processed, and returned inside your own browser tab. Nothing is uploaded to a server, which is also what makes the usual gates unnecessary: there's no server cost per use to recoup, so there's no reason to meter it, ask for an account, or charge for it.

The blog exists for the same reason as the tools: to actually answer the question instead of padding it out. If a guide explains a format or a concept better by linking straight to the tool that uses it, it does.

Who's behind it

GlaeKit is built and maintained by K. No large company, no venture funding, no roadmap driven by a subscription tier — just tools built to solve a problem I ran into constantly, kept free because the reason they were annoying in the first place was never a real cost problem to begin with.