DocuConvert Pro

Local-first PDF ↔ DOCX conversion

I owned DocuConvert Pro end to end: product concept, dual-mode architecture, React UI, browser-side conversion, a localhost conversion bridge, and an Electron wrapper with a portable Windows build. The app targets people who need PDF ↔ Word without uploading sensitive files to the cloud—offering quick in-browser conversion and an optional high-fidelity path through Word (COM) or LibreOffice on the same machine.

High-fidelity mode uses a loopback HTTP API only—no remote API—so files stay local while layout stays closer to the source than typical pure-browser pipelines.

Role Product design, front end, bridge API, Electron packaging

Platform Windows · Portable .exe · Localhost bridge

Stack React 19 · Vite 8 · Tailwind 4 · Electron 34 · Node

Output Shipped desktop artifact + documented bridge API

DocuConvert Pro — file upload and mode selection

File upload — choose input, direction, and browser vs. high-fidelity mode.

Problem & approach

Why local-first conversion

Cloud converters add privacy and compliance risk. In-browser tools are fast but can lose complex layout. Relying only on an Office UI is hard to automate from a simple product surface.

DocuConvert Pro combines two paths: browser mode (Mammoth, jsPDF, PDF.js, docx via CDN) for text-heavy turnaround, and bridge mode—a small Node server on localhost that shells out to Word or LibreOffice for truer fidelity, with payload limits and engine preference in the API contract.

DocuConvert Pro — conversion complete with download

Completion — result ready with a clear download step.

Stack

Technologies

Layer	Stack
UI	React 19, Vite 8, Tailwind CSS 4 (`@tailwindcss/vite`), Lucide React
Language	JavaScript (`.jsx`), JSDoc-style notes — not TypeScript in this repo
Desktop	Electron 34, electron-builder (Windows portable x64)
Local API	Node `http` server (`bridge/server.mjs`), `child_process` for PowerShell and `soffice`
Automation	PowerShell (`word-convert.ps1`, optional repair script)
Browser conversion	Mammoth, jsPDF, PDF.js, docx (UMD from CDN)

What was shipped

Deliverables

Product & architecture

Dual-mode conversion (client-side vs. local Office engines) with a clear privacy story: loopback bridge, no upload on the high-fidelity path.

Frontend & bridge

React UI with file pickers, mode selection, bridge health and capability checks, download flow, and dynamic loading of CDN libraries for browser mode. Local HTTP API with GET /capabilities, POST /convert, limits, and engine orchestration.

Desktop & docs

Electron spawns the bridge as a child process; electron-builder produces a portable Windows artifact. README covers setup, API, env vars, and troubleshooting.

How I built it

Process

01 Define modes Separate fast browser conversion from faithful local engines and document when each wins.

02 Ship UI shell Vite + React + Tailwind v4 for mode selection, status, and downloads.

03 Browser pipeline Wire Mammoth, PDF.js, jsPDF, and docx with lazy CDN loading.

04 Bridge API Implement capabilities, conversion, and engine preference on localhost only.

05 Electron Package UI + auto-started bridge; portable build for non-developers.

Screens & demo

Gallery

Representative UI only; demo video walks the full flow.

File upload

Result / completion

Demo video

Screen recording — DocuConvert Pro walkthrough.

Contribution

Ownership

Product & architecture — Dual-mode flow with an explicit privacy story.
Frontend — React UI, Tailwind v4, bridge health, lazy CDN libraries.
Browser pipeline — PDF ↔ DOCX logic in the client.
Backend bridge — Local HTTP API, limits, Word COM vs. LibreOffice.
Desktop — Electron integration and portable Windows artifact.
Documentation — README for setup, API, env vars, troubleshooting.

← All Projects