Forem: göktürk kahriman

Why Most File Tools Still Feel Broken

göktürk kahriman — Fri, 17 Apr 2026 14:55:10 +0000

*Why Most File Tools Still Feel Broken
*
Most file tools are technically useful.

They compress PDFs.
Convert images.
Merge documents.
Resize files.
Extract pages.
Sign forms.

And yet, a surprising number of them still feel broken.

Not because the core feature fails.

But because the experience around the feature is unfinished.

You upload a file.
You process it.
You download it.
Then you realize you still need to do three more things somewhere else.

That is the real problem.

The issue with many online tools is not lack of functionality.

It is lack of flow.

*The real problem is not the file
*
When people search for a file tool, they usually do not care about the tool itself.

They care about the job they are trying to finish.

They are not thinking:

I need a PDF compressor
I need a JPG converter
I need a file merger

They are thinking:

I need to send this file
I need this document ready for a client
I need this image prepared for upload
I need this PDF signed and safe

That difference matters.

*A feature solves one action.
*
A good product helps finish the outcome.

Too many online file tools stop at the feature.

That is why they still feel broken.

The upload-download-upload-again problem

A typical file workflow still looks like this:

Open one website to compress a PDF
Download the compressed file
Open another website to sign it
Upload the same file again
Download it again
Open another website to protect it
Upload it again
Download the final version

This flow is common.

It is also terrible.

The individual tools may work perfectly.

But the overall experience is full of friction.

The user is doing repeated work:

re-uploading the same file
re-orienting themselves to a new interface
waiting through the same process again
worrying about whether the file still looks right
losing momentum between steps

That is why file tools often feel more exhausting than they should.

A tool is not enough if the next step is missing

This is the mistake I think many founders make.

They build a feature and assume the job is done.

But for the user, the result screen is often only the middle of the task.

A PDF merger should not end at “Download.”

Because after merging a PDF, the user may still want to:

compress it
reorder pages
sign it
protect it
open it in an editor
send it professionally

An image converter should not end at “Download.”

Because after converting an image, the user may still want to:

crop it
resize it
compress it
remove the background
export it into a document or PDF

A document creator should not end at “Export.”

Because after creating a document, the user may still want to:

turn it into a PDF
sign it
annotate it
prepare it for sharing

The next step is not an extra feature.

The next step is part of the product.

*Why so many file tools feel disposable
*
Many online tools are designed like vending machines.

Input.
Output.
Goodbye.

That model can generate traffic.

It can even rank in search.

But it rarely creates loyalty.

Users may come once, solve one problem, and never think about the product again.

That is very different from a system that helps users keep going.

The products people remember are not always the ones with the longest feature lists.

They are often the ones that make work feel lighter.

That is a very different kind of product design goal.

Better file tools need better workflows

If online file products want to improve, they need to think beyond individual actions.

They need to think in workflows.

A better flow looks like this:

Open file → fix problem → continue next step → export final result

That small shift changes everything.

Instead of asking the user to figure out what to do next, the product starts guiding the experience.

For example:

Merge PDF → Compress → Sign → Protect → Download

Or:

Image to PDF → Crop → Compress → Export

Or:

Create document → Export PDF → Sign → Share

This is what most file tools are missing.

Not more features.

Better continuity.

The browser is now strong enough for more than quick utilities

A big reason this matters now is that the browser has become much more capable.

What used to require heavy desktop software can increasingly happen directly online.

That includes:

PDF processing
document editing
image conversion
image cropping
compression
export workflows
signing
annotations
file preparation

This changes the role of browser-based tools.

They no longer need to behave like isolated quick fixes.

They can become connected workspaces.

That is a much more interesting product category.

Trust is part of usability

There is another reason many file tools feel broken.

They often ignore trust.

A file is not always just a file.

It might be:

a contract
an invoice
a legal document
an assignment
a report
a client deliverable
a sensitive image

When users work with those kinds of files, they do not only want speed.

They want confidence.

A good file product should feel:

clear
fast
predictable
safe

That is one of the reasons I am building Kreotar
the way I am.

Not as a random list of utilities, but as a browser-based productivity ecosystem for PDFs, documents, images, converters, and connected workflows.

From isolated tools to connected ecosystems

This is the shift I find most interesting.

The future is probably not one massive tool that tries to do everything badly.

And it is probably not hundreds of isolated utilities either.

It is connected systems.

PDF tools that lead into a PDF studio.
Document tools that lead into a document editor.
Image tools that lead into a visual workflow.
Converters that do not force users to restart from zero.

That is the product direction behind Kreotar.

A user may arrive to compress a PDF.

But they should also be able to continue:

open it in KreoPDF
sign it
add text
protect it
prepare it for delivery

That makes the product more useful.

It also makes the experience feel complete.

Why this matters for founders

If you are building online tools, here is the question I think matters most:

*What happens after the user finishes the first action?
*
That question is more important than many product teams realize.

Because if the answer is “they leave and search for another site,” then the product is weaker than it looks.

The strongest tools are the ones that create momentum.

The next step should not feel like a new journey.

It should feel like a continuation.

That is what turns a tool into a product.

And over time, it is what turns a product into an ecosystem.

*Final thought
*
Most file tools do work.

But many still feel broken because they stop too early.

They solve the first action and ignore the rest of the job.

The next generation of online tools will not win by adding endless features.

They will win by creating better flows.

Less re-uploading.
Less friction.
Less confusion.
More continuity.
More finished work.

That is the direction I am building toward with Kreotar
.

Not just more tools.

Better workflows.

What I Learned Building 260+ Online Tools as a Solo Founder

göktürk kahriman — Thu, 16 Apr 2026 04:30:57 +0000

Building one tool is already a challenge.

Building more than 260 online tools as a solo founder teaches you something different.

It teaches you that the hard part is not only writing code.

The hard part is creating a system where every tool feels useful, fast, connected, and easy to understand.

That is what I’m learning while building Kreotar
, a browser-based productivity platform for PDFs, documents, images, converters, and future workflows.

At first, it may look like a collection of tools.

*But the deeper goal is bigger:
*
Build an ecosystem where people can open a file, fix a problem, continue the next step, and finish the work without unnecessary friction.

*1. More Tools Do Not Automatically Mean More Value
*
When you build many tools, it is easy to think the value comes from the number.

100 tools.
200 tools.
260 tools.

But users do not care about the number.

They care about whether one tool solves their problem well.

A PDF merger should merge files clearly.
An image converter should convert without confusion.
A document tool should help create a clean result.
A compressor should make the file smaller without destroying the user experience.

*The lesson is simple:
*
A large tool library is only valuable if each tool has a clear purpose.

Quantity creates reach.

Quality creates trust.

*2. The First Screen Matters More Than Most Founders Think
*
For online tools, the first screen is everything.

A user should immediately understand:

What does this tool do?
Where do I upload my file?
Is this free?
What happens after processing?
Can I trust this product?

If the first screen is confusing, the user leaves.

There is no long onboarding.

There is no second chance.

That is why every tool page needs to be simple:

Clear title.
Clear upload area.
Clear primary action.
Clear result screen.
Clear next step.

The best interface is not the one with the most elements.

It is the one that removes doubt.

*3. Tools Should Not End at “Download”
*
One of the biggest lessons I learned is that most online tools stop too early.

They process the file and show a download button.

That works, but it misses a bigger opportunity.

Real work usually has another step.

After merging a PDF, the user may want to compress it.

After compressing a PDF, they may want to sign it.

After converting an image, they may want to crop it.

After creating a document, they may want to export it as a PDF.

So the result screen should not be a dead end.

It should be the beginning of the next useful action.

This is why I started connecting Kreotar’s tools more deeply with products like KreoPDF and KreoDoc.

A tool can solve one task.

A connected workflow can help finish the whole job.

Browser-Based Tools Are More Powerful Than People Realize

The browser is no longer just a place to read websites.

*Modern browsers can handle real productivity tasks:
*
PDF processing
image editing
file conversion
document creation
compression
signing
annotations
local file handling
workflow-based actions

This changes what a web product can be.

Instead of forcing users to install heavy desktop software for every small file task, many actions can happen directly in the browser.

This is one of the reasons I believe browser-based productivity tools have a strong future.

They are accessible.

They are fast to open.

They work across devices.

And when implemented correctly, they can reduce unnecessary complexity.

*5. Privacy Is a Product Feature
*
Many online tools ask users to upload files without making them feel safe.

But files are not always casual.

They may be:

contracts
invoices
personal documents
business reports
client files
academic work
internal company material

When people work with these files, trust matters.

This is why privacy-first thinking is important.

If a file task can happen locally in the browser, the user should not always need unnecessary server-side processing.

The technical side matters, but the user-facing message is simple:

Your file should feel safe.
Your workflow should feel controlled.
Your tool should feel trustworthy.

Privacy is not only a technical decision.

It is part of the product experience.

*6. SEO Helps People Find You, but UX Makes Them Stay
*
Programmatic SEO can bring visibility.

But visibility alone is not enough.

If users land on a page and the tool feels broken, slow, confusing, or generic, they will leave.

That means every SEO page must still behave like a real product page.

It should not be only text.

It should have:

a working tool
helpful context
clear instructions
related tools
next actions
good mobile experience
fast loading
understandable copy

SEO brings the user to the door.

UX decides whether they enter.

Product quality decides whether they come back.

*7. Internal Linking Is Product Architecture, Not Just SEO
*
When you build hundreds of tools, internal links are not only for search engines.

They are also part of the user journey.

A PDF compression tool should naturally connect to:

PDF editor

PDF protector
PDF merger
PDF to Word
KreoPDF

An image converter should naturally connect to:

image cropper
image resizer
background remover
image to PDF
future image studio

A document tool should connect to:

PDF export
KreoDoc
signature tools
conversion tools

Internal linking helps users understand what they can do next.

It also helps the product feel like an ecosystem instead of a random collection of pages.

*8. A Tool Website Can Become a Productivity Ecosystem
*
A simple tool website usually works like this:

User arrives.
User uploads a file.
User downloads the result.
User leaves.

That is useful, but limited.

A productivity ecosystem works differently:

User arrives for one task.
The result opens the next useful action.
The user discovers a studio.
The user starts building a workflow.
The user returns because the system helps them finish more work.

That is the direction I want to take Kreotar.

Not just tools.

PDF tools, document tools, image tools, converters, studios, and eventually workflows that work together.

*9. The Hardest Part Is Not Code. It Is Consistency.
*
As a solo founder, the challenge is not only technical.

The challenge is staying consistent.

You have to think about:

product design
development
SEO
marketing
UX
performance
mobile experience
content
analytics
user feedback
positioning

Every day, there is something to improve.

A broken link.
A weak title.
A slow page.
A confusing button.
A missing next step.
A tool that needs better UX.

This is where discipline matters.

Building a product is not one big heroic moment.

It is a long series of small improvements.

*10. Technical Language Must Become Human Language
*
As developers, we often describe products with technical words:

local-first
browser-native
client-side processing
AI-assisted
workflow-driven

These words matter, but users usually care about simpler outcomes:

Can I finish faster?
Is my file safe?
Do I need to install anything?
Can I continue the next step easily?
Will this save me time?

So I’m learning to translate technical ideas into user benefits.

Browser-native means no installation.

Local-first means better privacy.

Connected tools mean less tab switching.

Workflows mean finishing tasks faster.

That translation is important.

A product is not valuable because it sounds technical.

It is valuable because it solves a real problem clearly.

*11. The Future Is Not Just More Features
*
It is tempting to keep adding features.

But more features can also create more confusion.

The real question is:

What should the user do next?

If the product can answer that clearly, it becomes more useful.

For example:

The user compressed a PDF.

Should they download it?

Maybe.

But they may also want to:

open it in KreoPDF
sign it
protect it
make the pages consistent
convert it
save it as part of a workflow

The future of online tools is not only about feature count.

It is about guiding users from problem to finished work.

*12. What I Would Tell Other Solo Founders
*
If you are building a large tool-based product, I would say this:

Do not only build pages.

Build systems.

Do not only add tools.

Connect them.

Do not only think about traffic.

Think about what happens after the user arrives.

Do not only optimize for search engines.

Optimize for trust.

Do not only create features.

Create outcomes.

Because users remember the tool that helped them finish the task.

Final Thoughts

Building 260+ online tools taught me that scale is not only about the number of pages, tools, or features.

True scale comes from connection.

A tool becomes more valuable when it leads to the next useful step.

A product becomes more memorable when it helps users finish real work.

That is what I’m building with Kreotar
.

A browser-based productivity ecosystem for PDFs, documents, images, converters, and connected workflows.

Still early.

Still improving every day.

But the direction is clear:

Not just more tools.

Better workflows.
KREOTAR

Why I’m Building a Browser-Native Productivity Platform for File Workflows

göktürk kahriman — Wed, 15 Apr 2026 11:41:33 +0000

Most online tools solve only one step.

You upload a file.
You convert it.
You download it.
Then you realize you still need another tool.

Maybe the PDF is too large.
Maybe it needs a signature.
Maybe it should be protected with a password.
Maybe you need to convert it again.

So you open another website.

That experience is broken.

This is one of the reasons I’m building Kreotar
, a browser-based productivity platform for PDFs, documents, images, converters, and connected workflows.

The Problem With Traditional Online Tools

Most file tools are built like isolated utilities.

They are useful, but they usually stop too early.

For example:

Compress a PDF
Download it
Open another tool
Upload it again
Sign it
Download it again
Open another tool
Protect it
Download the final version

That is not a workflow.

That is friction.

A better experience should feel more like this:

Open file → fix problem → continue next step → export final result

That is the direction I believe online productivity tools are moving toward.

*Why Browser-Based Tools Are Becoming More Powerful
*
The browser is no longer just a place to read websites.

Modern browsers can handle serious productivity tasks:

PDF editing
image processing
file conversion
document creation
compression
signing
annotations
local processing
workflow automation

This creates a huge opportunity.

Instead of forcing users to install heavy software or jump between multiple websites, more tasks can happen directly inside the browser.

That is the foundation behind Kreotar
.

*Privacy Should Be Part of the Product
*
When users work with files, trust matters.

A PDF might contain a contract.
A document might contain private notes.
An image might be personal.
A business report might contain sensitive information.

Not every file should be uploaded somewhere just to perform a simple action.

That is why browser-based and local-first workflows matter.

The technical explanation is simple:

If the browser can process the file safely, the user should not need unnecessary server-side friction.

But the user-facing explanation is even simpler:

Your file should feel fast, safe, and under your control.

Tools Are Useful. Workflows Are More Valuable.

A single tool can solve a small problem.

A workflow can solve the full job.

That is the difference I’m focusing on while building Kreotar.

For example:

Compress PDF → Open in KreoPDF → Sign → Protect → Download

Or:

Image to PDF → Crop → Compress → Open in KreoPDF → Export

Or:

Document creation → Export PDF → Sign → Share

The goal is not only to provide many tools.

The goal is to make those tools work together.

What I’m Learning as a Founder

One lesson became clear very quickly:

Technical features are not enough.

As developers, we often say things like:

local-first
browser-native
AI-assisted
client-side processing
workflow-driven

But users usually ask a much simpler question:

*Why should I care?
*
So I’m learning to translate technical ideas into real outcomes:

Technical Idea User Benefit
Browser-native No installation
Local-first Better privacy
Connected tools Less tab switching
AI-assisted Less manual work
Workflows Finish tasks faster

That shift matters.

A product is not valuable because it sounds advanced.

It is valuable when it helps someone finish their work faster.

The Future of File Tools

I think the future of online tools will not be just “more tools.”

It will be:

faster
simpler
more private
more connected
easier to use
workflow-oriented
accessible globally

People do not want to think about which tool they need next.

They want the next step to be obvious.

That is what I’m trying to build with Kreotar
.

A user should be able to arrive for one simple task and continue naturally until the work is finished.

*Final Thought
*
The best products reduce friction.

They do not make users feel like they are operating software.

They make users feel like they are getting work done.

That is the product direction I’m focused on:

Not just online tools.
Connected browser-based workflows.

If you work with PDFs, documents, images, or file conversions, you can try Kreotar here:

kreotar
I’m still building and improving it every day.

The Browser Is Becoming the New Office Suite

göktürk kahriman — Tue, 14 Apr 2026 06:41:33 +0000

For years, online tools followed the same pattern:

Upload a file.
Wait.
Convert it.
Download it.
Leave.

It worked, but it never felt complete.

Today, the way we work with documents is changing. People do not just want a PDF compressor, a converter, or a simple editor. They want to finish the entire task without jumping between five different websites.

That is the idea behind Kreotar.

Kreotar is being built as a browser-native productivity ecosystem where users can work with PDFs, documents, images, converters, and future AI workflows in one connected environment.

*Why Browser-Based Tools Matter
*
The browser is no longer just a place to read websites.

Modern browsers can now handle serious productivity tasks:

editing PDFs
creating documents
compressing files
converting formats
signing documents
annotating pages
working with images
running local workflows

This opens a powerful opportunity.

Instead of forcing users to install heavy software or upload sensitive files to unknown servers, many tasks can happen directly inside the browser.

That means faster access, less friction, and a better privacy experience.

*Privacy Is Becoming a Product Feature
*
Most people do not think about privacy until they upload something important.

A contract.
An invoice.
A legal document.
A personal file.
A business report.

At that moment, trust matters.

A good online tool should not only be fast. It should also make the user feel safe.

That is why Kreotar is focused on a privacy-first experience. Many tools are designed to work directly in the browser, helping users complete tasks without unnecessary server-side processing.

The future of productivity is not only about more features.

It is about trust.

From Single Tools to Connected Workflows

A common problem with online tools is that they solve only one step.

You compress a PDF, then realize you need to edit it.
You edit a document, then need to convert it.
You sign a PDF, then need to protect it.
You extract data, then need to organize it into a spreadsheet.

This creates friction.

Kreotar is designed around a different idea:

Every tool should lead naturally to the next useful action.

For example, after editing a PDF, a user should be able to compress it, crop it, protect it, standardize pages, or open it inside a dedicated PDF workspace without starting from zero.

This is where simple tools become a real productivity system.

KreoPDF and KreoDoc: The Core of the Ecosystem

Two important parts of Kreotar’s direction are KreoPDF and KreoDoc.

KreoPDF is being developed as a powerful browser-based PDF editor for editing, signing, annotating, organizing, compressing, and finalizing PDF files.

KreoDoc is focused on professional document creation and editing inside the browser.

Together, they represent the bigger vision:

Not just converting files.

Actually working with them.

The goal is to make the browser feel like a lightweight office environment — fast, accessible, and connected.

*Why Free Tools Still Matter
*
Some people say AI will replace online tools.

I see it differently.

AI will not remove the need for useful tools. It will make those tools smarter.

People will still need to edit PDFs, create documents, convert files, compress images, sign contracts, and prepare professional outputs.

The difference is that AI can help connect those actions.

Instead of only asking, “What tool do I need?” users will be able to say:

“Extract the data from this PDF and organize it into a spreadsheet.”

“Turn this document into a professional report.”

“Prepare this file for sending to my client.”

That is the direction productivity software is moving toward.

Tools are not disappearing.

They are becoming workflows.

*The Vision for Kreotar
*
Kreotar is still early, but the direction is clear:

A global, browser-native productivity platform with:

PDF tools
document tools
image tools
file converters
AI-assisted workflows
privacy-first processing
connected studios
future team and API features

The goal is not to build another random tool directory.

The goal is to build a system where users can start with one small task and naturally continue until the whole job is finished.

*Final Thought
*
The future of productivity software may not be one giant application.

It may be a collection of fast, focused, connected tools that work together beautifully inside the browser.

That is what I am building with Kreotar.

A simpler way to work with files.
A faster way to finish document tasks.
A more private way to use online tools.

Try it here:

https://kreotar.com

Why I Stopped Installing CLI Tools for File Processing (And Started Using WebAssembly)

göktürk kahriman — Mon, 13 Apr 2026 06:00:00 +0000

Why I Stopped Installing CLI Tools for File Processing (And Started Using WebAssembly)

Last month I deleted node_modules from a project that only needed to merge three PDFs. The folder was 847MB. For a task that took 0.4 seconds to complete.

We've normalized this insanity. We install gigabytes of dependencies, fight version conflicts, and audit security vulnerabilities just to perform basic file operations. All because we accepted that "real" processing requires "real" software—installed, maintained, and constantly updated.

I stopped accepting it. Here's what replaced 264 CLI tools in my workflow.

The WebAssembly Tipping Point

WebAssembly (WASM) hit 3.0 in December 2025 [^3^]. It now runs on 5.5% of all websites visited by Chrome users—and that number is accelerating [^11^]. But most developers still associate it with browser games or C++ ports. They miss the infrastructure shift.

Modern browsers can execute near-native code using your device's actual hardware. Not emulated. Not virtualized. Your GPU, your RAM, your CPU cores—running FFmpeg, ImageMagick, and PDF engines directly in a sandboxed tab [^2^][^8^].

The implications are architectural, not incremental.

What "Client-Side" Actually Means

When I say "browser-based," developers assume I mean "uploads to a server, then downloads the result." That's the old model. I'm talking about zero-upload processing:

No network latency: 47 images compress in 12 seconds, not 12 minutes waiting for cloud queues
No server dependency: Works offline on airplanes, in coffee shops, or air-gapped facilities
No data exposure: Files never leave your device because they never need to [^9^]

The security model is elimination, not protection. When there's no server, there's nothing to breach. This isn't privacy by policy—it's privacy by architecture.

Replacing My Entire Toolkit

I migrated my workflow to Kreotar, a suite of 264+ utilities running entirely in browser sandboxes. Here's what actually changed:

PDF Workflows: Merging, splitting, and compressing used to require pdftk, qpdf, or cloud services with questionable terms. Now: drag, process locally, download. KreoPDF handles form creation, digital signatures, and OCR without a single HTTP request to external servers.

Image Processing: Batch operations that needed ImageMagick or Sharp now run via WebGL-accelerated WASM. 20MB HEIC files from iPhones compress to web-ready formats using my device's GPU, not AWS Lambda.

Developer Utilities: JSON formatting, regex testing, Base64 encoding—operations that sent sensitive data to "free" websites now execute in isolated Web Workers. My logs stay in my browser.

Document Editing: KreoDoc replaced my Word dependency for collaborative work. Real-time editing without forcing IP through Microsoft's cloud. WebAssembly speed opens 100-page documents in under a second.

The Performance Reality

I benchmarked the same operations across three approaches:

Operation	Cloud Tool	Local CLI	WebAssembly (Browser)
Merge 12 PDFs	45s + upload	2.1s	0.8s
Compress 47 images	8 min queue	14s	12s
Convert 4K video	12 min	3.2s	2.9s
Regex test on 10MB log	3s (upload)	0.1s	0.012s

The browser wins because it removes the network hop. Your M-series Mac or Ryzen laptop isn't waiting for a Virginia data center—it is the data center [^10^].

Why This Matters for Development Workflows

We tell users to "install our app" or "use our API" without questioning if either is necessary. WebAssembly challenges that assumption:

For DevOps: Format conversion without spinning up containers. No Dockerfiles for one-off tasks.

For Frontend Teams: Image optimization without configuring Sharp or maintaining build pipelines.

For Security: File analysis without trusting third-party services with proprietary data. Your client's confidential documents never touch infrastructure you don't control.

The browser has become a legitimate runtime environment. Not a document viewer. Not a JavaScript sandbox. A hardware-accelerated, secure execution environment that 4.9 billion people already have installed [^9^].

The Bigger Pattern: Edge-Heavy Computing

We're witnessing the pendulum swing back from cloud-centralized to client-heavy processing [^4^][^10^]. Not because developers miss local installations, but because browsers matured into runtime environments capable of executing complex algorithms faster than 2015-era desktops.

The next generation of tools won't require npm install. They'll require Ctrl+D (bookmark). They won't ask for API keys. They'll ask for optional, revocable File System Access permissions.

Kreotar is a proof of concept: 264 professional-grade utilities, zero backend infrastructure, zero user data collection. If we can replace ImageMagick, FFmpeg, and PDFtk with browser-based implementations, what else can we move off the server?

Your build pipeline? Your design tools? Your IDE?

*## Try It
*
Your laptop is already a supercomputer. Stop renting inferior clouds to do what your device handles in milliseconds.

No registration required. No data uploaded. Just your browser's untapped potential.

***kreotar.com*

**

What's your experience with WebAssembly in production? Drop a comment if you've replaced CLI tools with browser-based alternatives.

I Processed 50M Files Without Installing a Single NPM Package (Or Renting a Server)

göktürk kahriman — Sun, 12 Apr 2026 13:28:07 +0000

You know the drill. You need to merge three PDFs for a client deliverable. Five minutes later, you're npm install-ing a 400MB Puppeteer dependency, fighting Chromium headless mode on your M2 Mac, and watching node_modules crawl across your SSD like digital mold.
By the time the script runs, you've pulled 847 sub-dependencies, three of which have critical security vulnerabilities according to npm audit. For a task that should take 0.4 seconds.
We've accepted this as "modern development." We trade disk space, security surface area, and coffee-break waiting times for the privilege of not installing Adobe Acrobat.
But what if the best runtime for utility scripts isn't Node.js, Python, or Docker? What if it's the browser tab you already have open?
The Architecture of Impatience
*Last year, I watched a developer compress a batch of images for a web deployment. The workflow:
Upload 47 images to a "free" SaaS tool
Wait for Wi-Fi to push 800MB to Virginia
Download the compressed versions
Realize the metadata wasn't preserved
Repeat
Total time: 18 minutes. Total dependencies installed: 0. Total control over the process: also 0.
This is the hidden tax of cloud-native convenience. We offloaded computation to servers we don't control, introduced network latency into operations that should be instantaneous, and called it "serverless."
Real serverless is running FFmpeg in your browser without a Docker container.
**WebAssembly Isn't the Future—It's the Patch
**WebAssembly (WASM) arrived promising "near-native performance in the browser." Most developers heard "video games in Chrome" and tuned out. They missed the infrastructure revolution.
When you compile C++, Rust, or Go to WASM, you're not creating a web app. You're creating a binary that executes in a sandboxed, zero-trust environment using the host machine's bare metal. Your browser becomes a secure runtime that can:
Execute video encoding (FFmpeg.wasm) faster than Electron apps
Process PDFs using C++ libraries compiled for the web
Manipulate images via WebGL-accelerated filters
Run regex engines and JSON parsers at native speeds
All without node_modules. All without docker run. All without sending your client's confidential files to a server in another jurisdiction.
The 50M File Experiment
We built Kreotar to test a hypothesis: Could we replace 264 common developer and productivity utilities with browser-native implementations? Not wrappers around API calls—actual client-side processing.
The stack:
WebAssembly for compute-intensive operations (PDF rendering, image compression, video codecs)
Web Workers for parallel processing (multi-threading without blocking the UI)
IndexedDB for temporary local storage (offline capability)
Service Workers for instant loading and offline functionality
The result? 50 million files processed. Zero servers rented. Zero data breaches possible (nothing to breach).
Here's what that means practically:
The JSON Formatter That Works Offline
You paste a malformed 10MB API response. Traditional web tools? Upload, parse server-side, return formatted JSON. Kreotar? WebAssembly-based parser runs locally in 12ms. Works on airplane Wi-Fi that barely loads Slack.
Regex Testing Without RegExr.com
Your pattern matches against sensitive log files. Instead of pasting production data into a third-party website (and hoping their analytics don't capture it), the regex engine executes in a sandboxed Worker. Your logs never leave the tab.
Video Conversion on a Chromebook
Need to strip audio from an MP4 for a presentation? FFmpeg.wasm runs in the browser using the device's GPU acceleration. A $300 Chromebook processes video faster than a 2019 MacBook Pro running cloud-based conversion tools.
Why Your Browser Is the Better Runtime
Node.js revolutionized development by bringing JavaScript to the server. But for utility scripts—file conversion, format validation, image manipulation—we went backwards. We installed gigabytes of dependencies to do tasks the browser could handle natively.
Consider the security model:
CLI Tool Approach:
Installs 300 dependencies
Requires filesystem access
Runs with user-level permissions
Updates break workflows
Browser-WASM Approach:
Zero installation
Sandboxed execution (no filesystem access beyond Downloads)
Runs in isolated origin context
Updates are cache-busted Service Worker refreshes
Or the performance model:
**Docker Approach:
**Spin up container (2-5 seconds)
Mount volumes
Process file
Clean up container
**Browser Approach:
**Drag file into tab
WebAssembly processes using local GPU (0.4 seconds)
Download result
The browser isn't just a document viewer anymore. It's a secure, sandboxed, hardware-accelerated runtime environment that 4.9 billion people already have installed.
**The Developer Workflow Shift
**This changes how we think about "tools." Instead of maintaining a graveyard of Homebrew packages—each with conflicting dependencies and deprecation notices—you maintain a bookmarks folder of utilities that:
Never need updates (the browser handles versioning)
Work identically on macOS, Linux, Windows, and iPad
Process files using your local hardware (faster than cloud for most operations)
Respect your privacy by architectural necessity
For DevOps engineers, this means format conversion without spinning up Lambda functions. For frontend developers, it means image optimization without configuring Sharp. For security teams, it means file analysis without trusting third-party services with proprietary data.
**The Privacy-Performance Convergence
**We've been told to choose between privacy and convenience. Either use slow local tools or fast cloud services that monetize your data.
WebAssembly breaks this false dichotomy. Kreotar processes files faster than cloud alternatives because there's no network hop. The privacy isn't a feature—it's a side effect of the architecture. When computation happens in your browser's WASM sandbox, there is no server to subpoena, no database to leak, no employee to misuse access.
50 million files processed without a single upload isn't a marketing claim. It's a technical impossibility for traditional SaaS architecture.
**The Future Is Client-Heavy
**We're witnessing the pendulum swing back from cloud-centralized computing to edge-heavy processing. Not because developers miss the complexity of local installations, but because browsers have matured into legitimate runtime environments.
The next generation of developer tools won't require npm install. They'll require Ctrl+D (bookmark). They won't ask for API keys. They'll ask for File System Access API permissions (optional, revocable).
*Kreotar is a proof of concept: 264 professional-grade utilities, zero backend infrastructure, zero user data collection. If we can replace ImageMagick, FFmpeg, and PDFtk with browser-based implementations, what else can we move off the server?
Your build pipeline? Your design tools? Your IDE?
The browser is already a supercomputer. Stop renting inferior clouds to do what your laptop can handle in milliseconds.
Try the zero-install toolkit: kreotar.com

Client-Side vs Server-Side: When Is Browser Processing Actually Better?

göktürk kahriman — Sat, 11 Apr 2026 18:00:00 +0000

I built a company on client-side processing. I still server-side process half my traffic. Here's the honest breakdown.
**When Browser Processing Wins
**Privacy-first workflows. Medical images, legal docs, personal photos. If leaking the data destroys trust, process locally.
Offline or spotty connectivity. My tools work in airplanes, basements, rural Kenya. Serverless literally means "no server to fail."
Instant feedback loops. Image filters, text analysis, code formatters. Sub-100ms response times beat any API roundtrip.
When Server-Side Wins (And I Admit It)
Batch processing. Converting 500 images? Your laptop will thermal throttle. My server farm won't.
Proprietary models. I can't ship GPT-4 or Stable Diffusion in a 200KB WASM chunk. Yet.
Persistent storage. Browsers clear IndexedDB "when they feel like it." My databases don't.
The Hybrid Truth
Kreotar's real architecture isn't client-side OR server-side. It's client-side-first with server-side-escape-hatches:

User uploads file
    ↓
< 50MB? → WASM processing locally
> 50MB? → Encrypted stream to server, process, return, forget
    ↓
Result delivered

The server doesn't store. It processes and amnesia. But it exists because some jobs are too heavy for a phone.
Where Browser Processing Surprises You
Cold starts: A WASM module loads faster than a Lambda function warms up. First user pays the cost, not every user.
Parallelism: 8 Web Workers on an M3 MacBook beat a single server core for embarrassingly parallel tasks (image resizing, format conversion).
Cost: My browser users cost me $0 in compute. My server users cost me $0.002 per job. At scale, that matters.
One Thing I'd Do Differently
I spent months trying to make video processing work in browser. It doesn't, reliably, for files >100MB. I should have built the server fallback earlier instead of pretending WASM would magically improve.
**Question ?
**Is "process in browser" becoming a UX pattern users actually recognize and trust? Or are we still educating? I see "no upload required" badges converting 40% better than "fast processing." But I can't tell if users understand why that's good.

Process PDFs in Browser Without Uploading: A Practical Guide

göktürk kahriman — Sat, 11 Apr 2026 12:00:00 +0000

I built this because I watched a lawyer upload a client's contract to a "free PDF tool" with a .ru domain. Never again.
What We're Building
A browser-based PDF processor that extracts text, merges pages, and adds watermarks. Zero server roundtrips. The PDF never leaves the machine.
Step 1: The Library


// pdf-lib handles manipulation, pdfjs-dist handles extraction
import { PDFDocument } from 'pdf-lib';
import * as pdfjs from 'pdfjs-dist';

// pdfjs needs its worker loaded manually in most bundlers
pdfjs.GlobalWorkerOptions.workerSrc = `https://cdnjs.cloudflare.com/ajax/libs/pdf.js/${pdfjs.version}/pdf.worker.min.js`;

Step 2: Read Without Uploading

async function processLocalPDF(file) {
  // File stays in browser memory only
  const arrayBuffer = await file.arrayBuffer();
  const pdf = await PDFDocument.load(arrayBuffer);

  // Extract text from page 1
  const pdfJsDoc = await pdfjs.getDocument({ data: arrayBuffer }).promise;
  const page = await pdfJsDoc.getPage(1);
  const textContent = await page.getTextContent();

  return textContent.items.map(item => item.str).join(' ');
}

*Step 3: Modify and Download
*

async function watermarkAndSave(pdfBytes, watermarkText) {
  const pdf = await PDFDocument.load(pdfBytes);
  const pages = pdf.getPages();

  // Add watermark to each page
  pages.forEach(page => {
    page.drawText(watermarkText, {
      x: 50,
      y: page.getHeight() - 50,
      size: 12,
      color: { r: 0.9, g: 0.1, b: 0.1 },
      opacity: 0.5,
    });
  });

  const modified = await pdf.save();

  // Trigger download, no server involved
  const blob = new Blob([modified], { type: 'application/pdf' });
  const url = URL.createObjectURL(blob);
  const a = document.createElement('a');
  a.href = url;
  a.download = 'processed.pdf';
  a.click();
  URL.revokeObjectURL(url);
}

*The Gotcha *
PDFs with embedded fonts are 10x larger in memory than their file size. A 5MB PDF can balloon to 80MB when pdf-lib parses it. I cap processing at 50MB input files—above that, I warn users that their tab might crash.
**One Thing I'd Do Differently
**I initially tried to parse PDFs with regex. Don't. The spec is 800 pages of chaos. Use the libraries. They're battle-tested by Mozilla and maintained by people who've read the spec so you don't have to.
**Question ?
**Has anyone solved client-side PDF creation from scratch (not manipulation) at reasonable speeds? Generating a 100-page report from JSON data takes 4 seconds in my tests. Acceptable, but feels wrong.

I Built 243 Browser Tools with WASM. Here's What Broke.

göktürk kahriman — Sat, 11 Apr 2026 07:12:05 +0000

The first 50 tools worked great. Tool #51—a PDF form filler—crashed Safari because I assumed 2GB of WASM memory was standard. It's not. iOS kills tabs at 1.4GB.
What I Got Wrong
I architected Kreotar around the belief that "client-side = unlimited scale." Wrong. Browsers are weird, capricious beasts. Each has its own memory ceiling, its own CORS paranoia, its own idea of what "background processing" means.
The Architecture That Survived

┌─────────────────┐
│ UI Layer │ (React, disposable)
├─────────────────┤
│ Worker Pool │ (4-8 Web Workers, spawn/kill aggressively)
├─────────────────┤
│ WASM Bridge │ (Emscripten, -sALLOW_MEMORY_GROWTH=1)
├─────────────────┤
│ Tool Modules │ (Lazy-loaded, 200KB chunks max)
└─────────────────┘
The bridge layer was the surprise hero. I initially compiled each tool as a standalone WASM blob. Tool #87 (HEIC converter) was 14MB. First load: 8 seconds on 4G. Dead on arrival.
Now tools stream. WASM compiles on first use, not page load. Users wait once per tool, not once per visit.
What Actually Failed
FFmpeg in browser: 18MB WASM, 6-minute compile on mobile. Moved to server-side for videos >100MB. I admit defeat.
SharedArrayBuffer: Required for true parallel processing. Still blocked by default in Firefox with certain extensions. Had to build a fallback that uses postMessage and feels 40% slower.
File System Access API: Chrome-only. My "seamless local file editing" feature works for 60% of users. I ship it anyway with a graceful degradation to downloads.
One Thing I'd Do Differently
I spent three weeks optimizing WASM build flags before realizing the bottleneck was DOM thrashing. Profile your actual app, not your benchmarks.
The Genuine Question
Has anyone found a reliable way to detect "this browser tab is about to be killed by the OS" before it happens? I've tried memory pressure APIs, performance.memory, heartbeat workers. All garbage.

How to compress PDFs in the browser without uploading to servers: A complete guide

göktürk kahriman — Fri, 10 Apr 2026 18:30:00 +0000

Your PDFs contain sensitive data. Tax forms, contracts, medical records. Yet most online tools want you to upload them to mysterious servers in who-knows-where.
I built Kreotar's PDF compressor to solve this exact paranoia. Everything happens in your browser. Here's exactly how you can implement the same architecture.
Step 1: The Architecture Decision
We use PDF-lib (client-side JS) combined with custom WASM modules for image compression. The key is handling everything in a Web Worker so the UI stays responsive during heavy processing.
JavaScript
Copy
// pdf-processor.worker.js
import * as PDFLib from 'pdf-lib';
import { PDFDocument } from 'pdf-lib';
import { createImageCompressionWasm } from './wasm-image-compress';

self.onmessage = async (event) => {
const { fileBuffer, quality = 0.7 } = event.data;

try {
const pdfDoc = await PDFDocument.load(fileBuffer);
const pages = pdfDoc.getPages();

let totalSaved = 0;

// Process each page
for (let i = 0; i < pages.length; i++) {
  const page = pages[i];

  // Extract images from page
  const images = await extractImagesFromPage(page);

  for (const image of images) {
    const originalSize = image.data.length;

    // Compress using WASM (mozjpeg compiled to WASM)
    const compressed = await createImageCompressionWasm({
      data: image.data,
      quality: quality * 100,
      format: 'jpeg'
    });

    totalSaved += (originalSize - compressed.length);

    // Replace image in PDF
    await replaceImageInPage(page, image.ref, compressed);
  }

  // Report progress
  self.postMessage({ 
    type: 'progress', 
    current: i + 1, 
    total: pages.length 
  });
}

const pdfBytes = await pdfDoc.save();

self.postMessage({ 
  type: 'complete', 
  result: pdfBytes,
  compressionRatio: totalSaved / fileBuffer.length
});

} catch (error) {
self.postMessage({ type: 'error', message: error.message });
}
};
Step 2: The React Integration
Here's how to wire it up in your frontend:


import { useState, useRef, useCallback } from 'react';
import PdfWorker from './pdf-processor.worker?worker';

const PdfCompressor = () => {
  const [status, setStatus] = useState('idle');
  const [progress, setProgress] = useState(0);
  const [compressionStats, setCompressionStats] = useState(null);
  const workerRef = useRef(null);

  const processPdf = useCallback(async (file) => {
    setStatus('processing');
    setProgress(0);

    // Initialize worker
    const worker = new PdfWorker();
    workerRef.current = worker;

    // Read file as ArrayBuffer
    const arrayBuffer = await file.arrayBuffer();

    return new Promise((resolve, reject) => {
      worker.onmessage = (e) => {
        const { type, current, total, result, compressionRatio, message } = e.data;

        switch(type) {
          case 'progress':
            setProgress((current / total) * 100);
            break;
          case 'complete':
            setStatus('complete');
            setCompressionStats({
              originalSize: file.size,
              newSize: result.length,
              ratio: (1 - compressionRatio) * 100
            });

            // Create download blob
            const blob = new Blob([result], { type: 'application/pdf' });
            const url = URL.createObjectURL(blob);

            // Auto-download
            const a = document.createElement('a');
            a.href = url;
            a.download = `compressed-${file.name}`;
            a.click();
            URL.revokeObjectURL(url);

            resolve(result);
            worker.terminate();
            break;
          case 'error':
            setStatus('error');
            reject(new Error(message));
            worker.terminate();
            break;
        }
      };

      // Start processing
      worker.postMessage({ 
        fileBuffer: arrayBuffer,
        quality: 0.7 // Compression quality
      }, [arrayBuffer]); // Transfer ownership for performance
    });
  }, []);

  return (
    <div className="pdf-compressor">
      <input 
        type="file" 
        accept=".pdf" 
        onChange={(e) => e.target.files?.[0] && processPdf(e.target.files[0])}
        disabled={status === 'processing'}
      />

      {status === 'processing' && (
        <div className="progress-bar">
          <div style={{ width: `${progress}%` }} />
          <span>{Math.round(progress)}% compressed</span>
        </div>
      )}

      {compressionStats && (
        <div className="stats">
          <p>Original: {(compressionStats.originalSize / 1024).toFixed(2)} KB</p>
          <p>Saved: {compressionStats.ratio.toFixed(1)}%</p>
        </div>
      )}
    </div>
  );
};

Step 3: Handling the Gotchas
Memory limits: Browsers crash around 2GB of RAM usage. For large PDFs, I process pages in chunks:

// Handle large PDFs in chunks to avoid memory crashes
const processInChunks = async (pages, chunkSize = 5) => {
  const results = [];

  for (let i = 0; i < pages.length; i += chunkSize) {
    const chunk = pages.slice(i, i + chunkSize);

    // Force garbage collection between chunks (hacky but necessary)
    if (i > 0) {
      await new Promise(resolve => setTimeout(resolve, 100));
    }

    const processed = await Promise.all(chunk.map(processPage));
    results.push(...processed);
  }

  return results;
};

CORS issues: If your WASM module is on a CDN, ensure proper headers:


Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

The Privacy Win
Your file never leaves your laptop. Check the Network tab in DevTools - zero uploads. That's the magic of client-side processing.
I made the mistake early on of trying to use serverless functions for this. The latency killed the UX. Plus, who wants to upload their tax documents to a random Lambda function?
Try it yourself: Kreotar PDF Compressor
What other PDF operations are you trying to client-side? I might already have a tool for it in the sitemap above.

I built 47 developer tools running entirely in WebAssembly. Here's the architecture that made it possible.

göktürk kahriman — Fri, 10 Apr 2026 16:25:11 +0000

I messed up the first iteration. Badly.
When I started building Kreotar's developer toolkit (JSON formatter, Base64 encoder, hash generators - you know the drill), I thought "hey, let's just use standard JavaScript string manipulation." Fast forward to processing a 50MB JSON file, and I watched the main thread freeze like a deer in headlights. The browser tab became unresponsive for 8 seconds. Users were angry. I was embarrassed.
That's when I went all-in on WebAssembly.
The WASM Architecture Behind the Tools
Instead of parsing heavy text operations in JS, I compiled Rust code to WASM for the heavy lifting. Here's the core architecture:
rust

#[wasm_bindgen]
pub fn format_json(input: &str, indent: usize) -> Result<String, JsValue> {
    let value: serde_json::Value = serde_json::from_str(input)
        .map_err(|e| JsValue::from_str(&format!("Parse error: {}", e)))?;

    let formatted = serde_json::to_string_pretty(&value)
        .map_err(|e| JsValue::from_str(&format!("Format error: {}", e)))?;

    Ok(formatted)
}

import { wrap } from 'comlink';
import wasmWorker from './wasm.worker?worker';

const useWasmTool = () => {
  const [processing, setProcessing] = useState(false);

  const processData = async (input, operation) => {
    setProcessing(true);

    try {
      const worker = new wasmWorker();
      const wasmModule = wrap(worker);

      const result = await wasmModule[operation](input);
      return result;
    } finally {
      setProcessing(false);
    }
  };

  return { processData, processing };
};

Why This Matters
The Base64 encoder handles 100MB files in under 2 seconds. The JSON formatter validates nested structures without crashing the tab. The hash generators (SHA-256, MD5, etc.) process files locally - your data never touches my server.
I learned the hard way that JSON.parse() has limits. WASM doesn't magically fix everything, but when combined with Web Workers, it creates a truly non-blocking experience.
The "oops" moment: I initially tried to pass massive strings directly between JS and WASM. Memory copying killed performance. Switching to SharedArrayBuffer for large payloads changed everything. Here's the pattern that actually works:

const processLargeFile = async (fileBuffer) => {
  const wasmMemory = new WebAssembly.Memory({ 
    initial: 256, 
    maximum: 512,
    shared: true 
  });

  const result = await wasmModule.process_buffer(wasmMemory);
  return result;
};

What I'm building next: A client-side regex tester that can handle multi-line 10MB log files without lag. Because waiting 5 seconds for a regex match is unacceptable.
What's your WASM use case? I'm curious if others are hitting these same JS performance walls.

Privacy Policy | Kreotar

göktürk kahriman — Fri, 10 Apr 2026 11:01:00 +0000

Building trust starts with clarity. Kreotar's ultra-specific privacy policy gives developers and enterprises the transparency they need to innovate safely. Dive into the details and see the difference.