Hi everyone!
I built iCreatePDF out of sheer frustration with existing online PDF tools.
The Problem
Almost every popular PDF website requires you to upload your files to their remote servers to perform simple tasks like converting an image, merging pages, or adding page numbers. When dealing with sensitive files like tax documents, bank statements, contracts, or identity cards, uploading them to a third-party server is a massive privacy risk. The alternative is paying expensive monthly subscriptions for heavy desktop software.
Our Approach: 100% Local
iCreatePDF changes that. By leveraging modern browser capabilities and compiled WebAssembly (Wasm) engines (pdf-lib, pdfjs-dist, and heic2any), all calculations and document rendering happen entirely inside your browser sandbox. Your data never leaves your computer. In fact, once the web app loads, you can turn off your internet completely and all 36 tools will continue to work perfectly offline.
How the Project Evolved
What started as a simple script to convert iPhone HEIC photos into PDFs has grown into a comprehensive client-side PDF workspace containing 36 individual utilities. We've recently overhauled the interface to feature a minimal, modern, dark-mode SaaS design to make document editing clean and enjoyable.
The project is also fully open source, and you can check out the source code or host it yourself on GitHub: https://github.com/barath0508/iC....
I d love to hear your thoughts, feedback, and any features/tools you d like to see added next!
No server uploads sounds great for privacy, but how does the tool actually handle something like OCR or converting scanned PDFs to searchable text if everything is running locally?
@mertbileci Hi Mert,
Great question! It sounds counterintuitive that heavy workloads like OCR (Optical Character Recognition) can run locally, but modern browser technologies make it entirely possible. Here is exactly how iCreatePDF handles it under the hood without any server uploads:
1. In-Browser Rendering via PDF.js
First, the tool uses a library called pdfjs-dist (built by Mozilla) to load your scanned PDF document. It renders each PDF page onto an invisible HTML5 <canvas> element. This essentially converts the vector/image pages into high-resolution pixel buffers directly within your browser's memory.
2. WebAssembly (Wasm) Engine via Tesseract.js
For the actual OCR, the tool runs Tesseract.js—which is a port of the open-source Tesseract OCR engine (originally written in C++) compiled into WebAssembly.
WebAssembly (Wasm) allows compiled code to run inside your browser's JavaScript sandbox at near-native execution speeds.
The browser runs this processing in a separate Web Worker (background thread), preventing your browser tab or UI from freezing while OCR is executing.
3. Local Character Recognition & Dictionaries
The WebAssembly engine downloads the language dictionary files (such as English, Spanish, etc.) once, which are then cached locally by your browser.
The pixel buffer from the <canvas> is fed directly into the Tesseract Wasm engine.
The neural network recognition models inside the Wasm engine analyze the shapes, letters, and layout on the canvas and translate them back into clean, copyable Unicode text.
Everything is loaded, executed, and processed on your device's CPU/GPU within the browser sandbox. Because not a single byte of document data leaves your device, your private data remains completely secure and offline.
How well does the client-side merging and compression handle really large PDFs, like ones with hundreds of pages or huge embedded images? Curious if browsers start to choke on that or if you found a smart way around it.
@farukalayemdm Great question! For big PDFs (hundreds of pages / large images), iCreatePDF processes pages incrementally and uses Wasm + background workers so the browser doesn’t freeze, all while keeping everything fully local. In my tests with large docs it’s been stable, but if you hit a case where it struggles I’d love to check that file pattern and optimize.
Would love a batch OCR feature that runs locally too so I can extract text from scanned PDFs without uploading anything.
@kumsalmnyj That’s an excellent suggestion, Kumsal—thank you! A local batch OCR pipeline fits perfectly with iCreatePDF’s privacy-first philosophy, and your use case of extracting text from scanned PDFs without uploads is exactly what we want to support. We’re evaluating on-device OCR engines to keep everything local while still delivering good accuracy and performance. Once we have a prototype for batch OCR, I’d love to get your feedback on how it works for your documents.
love the local-only approach, that's the real draw here. one thing that would seal the deal for me is OCR on the merged output so i can search scanned PDFs and invoices. pretty please
@atakandeftsjbn Thanks Atakan, glad the local-only approach resonates with you! OCR on merged outputs is a great idea and very much aligned with what we want iCreatePDF to become—fast, searchable, and still fully local. We’re already exploring local OCR options that run on-device, so invoices and scanned PDFs can be searchable without sending anything to a server. If you’re open to it, I’d be happy to ping you when an OCR beta is ready so you can test it and share your thoughts.
Merged a few PDFs and added a signature in under a minute, no upload lag at all. Love that the files stay on my machine.
@remziunutu44051 Thanks a lot for trying iCreatePDF, Remzi! Keeping everything blazing fast and local was a core design goal, so it’s great to hear you could merge and sign in under a minute without any upload delay. Your files staying on your machine is exactly the experience we’re aiming for. If there are any other PDF workflows you use often, I’d love to hear them so we can optimize those next.
Finally found a PDF tool that actually keeps everything local, no surprise uploads. The merge and split worked smoothly on a few files I tested, and the fact that it runs offline is a huge plus for sensitive work.