docreplacer.online is a tool that converts a plain-English prompt into a formatted .docx file — entirely inside your browser. No server, nothing uploaded or stored remotely. You type a prompt, a Word document downloads. It's currently in MVP — free to use, no account required at this stage.
I built it. And the most interesting part of building it wasn't the document generation itself — it was the decision to use no backend at all, and what that choice forced me to think through.
I'm a developer who builds small tools to solve workflow problems. This one started as a minor utility for my own use and turned into a more considered architectural exercise than I expected. This post is about that process — what the problem was, how the client-side approach works in practice, and where it genuinely falls short.
Most side projects start with a problem. This one started with a boring observation: generating a .docx file from structured text is something browsers can already do — and almost nobody does it that way.
I wasn't trying to build a product. I was trying to avoid spinning up a server for something that didn't need one.
The Actual Problem
I was generating documents repeatedly — contracts, briefs, structured reports — where the content changed but the format didn't. The standard workflow: keep a Word template, open it, fill in the blanks, save-as, send. Manageable for one document. Tedious for twenty.
The obvious modern fix is AI. Feed a prompt, get content back. But AI gives you text. Turning that text into a properly formatted .docx — with correct heading levels, paragraph spacing, and section structure — still requires a human hand in Word.
That gap is small, but it compounds. And the tooling built to close it almost universally requires an account, a subscription, or a server that holds your files.
I didn't want any of that. So I looked at whether it was actually necessary.
The tools that exist to bridge this gap — AI writing assistants, document editors with template engines, cloud-based DOCX converters — all solve it server-side. Your prompt goes up, the file comes down, and somewhere in the middle your content passes through infrastructure you don't control. For most use cases that's a reasonable trade-off. For documents containing personal information, legal agreements, or internal business data, it's worth at least pausing on.
What the Browser Can Do
The docx JavaScript library constructs valid Office Open XML documents entirely in memory. No server. No conversion endpoint. The file is assembled in the browser and downloaded directly — the same way a client-side CSV export works, just more structurally complex.
This meant the architecture could be:
• Browser receives prompt
• AI API returns structured content
• docx library assembles the file client-side
• File downloads
No file ever touches a server I control. No authentication layer needed. No storage costs. No database.
The result is docreplacer.online — a tool that converts a plain-English prompt into a .docx file, runs entirely in the browser, and is free to use.
What "Client-Side Only" Actually Means in Practice
It means the tool has genuine constraints, and being honest about them is more useful than pretending otherwise.
What works well:
Document generation is stateless by nature. You have a prompt, you want a file. There's no meaningful user state to persist server-side, no collaboration requirement, no reason the process needs to leave the browser. Client-side architecture fits the problem well.
localStorage handles recent templates. The browser handles the download. The only external dependency is the AI inference call — which originates from the client and returns content, not a stored file.
Where it gets harder:
Large-scale batch generation isn't the right use case here. If you need to produce 500 documents from a data pipeline, you want a backend. This tool is for individuals generating documents on demand.
Template sharing across a team isn't supported in the current version. That would require either a sync layer or a server — which may be added later, but deliberately isn't there now.
These are real trade-offs, not oversights. The goal was to build the simplest thing that solved the problem without introducing infrastructure the problem doesn't require.
The Broader Point About Architecture Decisions
There's a habit in software development — understandable, given the tooling available — of reaching for a backend before asking whether one is necessary.
Servers solve real problems: persistence, authentication, multi-user access, compute-intensive operations. But they also introduce real costs: hosting, maintenance, security surface area, latency, and for users, the ongoing question of what happens to their data.
For a certain class of tools — document generation, data formatting, local calculations, file conversion — the browser is sufficient. WebAssembly, modern JS libraries, and browser storage APIs have expanded what's possible client-side considerably in the past five years.
The question worth asking before spinning up a server is: what does the server do here that the client can't? Sometimes the answer is obvious. Sometimes it isn't, and the server exists out of habit.
This isn't an argument for never using backends. It's an argument for making the choice deliberately rather than by default.
Where This Is Going
The current version is an MVP. It handles single-document generation from a prompt, with basic formatting and section structure.
Planned additions include template saving, more granular formatting control, and better handling of complex document structures (tables, multi-column layouts). Whether any of those features require server infrastructure will be evaluated when the time comes — not assumed in advance.
If you work in an environment where documents contain sensitive information — legal, medical, HR, financial — the client-side architecture is worth understanding. Nothing is transmitted to a storage layer. The document exists in your browser's memory and then on your local file system. That's a meaningful property for certain workflows, and one that's difficult to replicate credibly with a server-based tool.
Try It
docreplacer.online is currently free to use — a free tier will remain available in the full version.
A few prompts worth testing if you want to see the range:
• A consulting services agreement with payment terms and IP ownership clauses
• A technical specification document for a REST API
• A performance review template for quarterly engineering team reviews
One thing worth noting: the output is a standard .docx file. It opens in Microsoft Word, Google Docs, LibreOffice — anywhere that reads the Office Open XML format. There's no proprietary format, no export step, no compatibility issue. It's just a Word document, generated from a prompt.
Feedback on document quality, formatting gaps, or missing features is genuinely useful at this stage — the tool is early and the edge cases are being found in real use.
The author built docreplacer.online as a client-side document generation tool. It is currently in MVP — free to use, with a free tier planned for the full release.
Top comments (0)