Show HN: Free, in-browser PDF editor
breezepdf.com
Add text, input boxes, pictures, signatures, delete pages, merge PDFs and password protect them. All happening in the browser, 100% free and no sign-up.
breezepdf.com
On a similar note, a downloadable (single-file HTML or so, although these days some kind of HTTP service is a practical necessity) version would be nice to have. Low pri even from my perspective; it isn't that I spend a lot of time in places with no cell signal, so much as just that tethering on an a la carte plan gets out of hand pretty quick, since applications aren't at all required to honor or even notice the existence of the "data saver" option.
This is really neat! Thanks for posting it, I've bookmarked it for later use in the "just need a quick tweak" kind of case. I'll look forward to seeing how it develops!
Modern processors can handle the relevant conversion math without really waking from sleep, which will no doubt make it more frustrating when some W3C third party resource security model WG fistfight from 2013 makes it impossible to both construct and use a webfont on the client. (There may be some hideous blob URL magic, but those are length constrained so you could up in N subset nonce fonts bucketing M custom glyphs from the source document, with a hideously complex fifty-case rewrite for all the p90 ways of mapping fonts in PDF (or is that 90 cases and p50?) to render the document in the editor. And then have to handle the actual editing cases, like what happens when your subset nonce font of a subset embedded font doesn't map any character to the keycode you just saw, and you want to try to give the user something with metrics sorta matching what they wanted instead of Helvetica or Times New Roman out of a naïvely constructed fontset.
I may have worked with PDF in browsers one time too many, before. But the idea of using WASM to smuggle real tools into this impoverished environment actually makes a lot of sense to me...
I'll take a look at improving rendering embedded font support. And that's a neat idea to be able to download it for offline, I'll give some thought to that. Appreciate your feedback!
Since I like an iPhone - or have thought at least they're least worst for 13 years and counting - you can probably imagine how this would have depressed my interest: Even though irrelevant here in that touchscreen PDF editing is an extremely hard problem and none I'd expect a solo dev to address, just knowing nothing I built with a worker I would myself be able to use, has made me not want to sink good time and effort into the topic at all. Best case that's all just wasted; worst case, it creates a dilemma I might not escape without a new regret.
As far as touchscreen PDF editing, that is 100% doable and something I plan on adding soon. Touchevents are supported natively in the web
https://developer.mozilla.org/en-US/docs/Web/API/Touch_event...
PWAs are basically "installable" pages which open in their own browser window and generally can work offline
[1] https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
* Need to make a relatively narrow change to a PDF (add a line, reorder pages, concatenate two files)
* Adobe is $$$ and pretty much a subscription-only fiasco. Even the most trivial tasks are paywalled.
* Even if you're paying for Adobe at a corporate level, getting the IT clearance to get it installed might be more time sink than the actual task,
We have a server that had pdftk installed to generate some pre-filled documents and I ended up using that to concatenate two PDF files instead of fighting to get Real Acrobat.
I think I see you're using pdf-lib and jspdf - both great libraries, and I'm using both, but:
(1) Have you seen the recent WASM compilation of MuPDF? I am also using it for some functions and find it really excellent with accessible APIs and highly functional. Worth an try!
(2) We chose different forks of the (unmaintained) pdf-lib - is there a reason you went with `pdf-lib-plus-encrypt`? I chose the cantoo fork, which seemed well-maintained to me - but I didn't research many others so would be interested to know if there is a good reason.
Since a lot of the basic functionality I've added so far is also covered by more permissible packages like the ones you mentioned, I've started out just using those. But thanks for bringing that up, I'll revisit using MuPDF for redaction and other features
(2) I went with pdf-lib-plus-encrypt because the original pdf-lib doesn't have functionality for password-protecting PDFs, and since pdf-lib-plus-encrypt does, I used it so I could have that feature
On the first part, since everything happens in the browser, anyone can see the html/javascript and inspect the Network tab and see that no network requests are made that send their PDF anywhere.
And on the second part, I think most people who use the software aren't developers and won't want to modify it, and I don't particularly see a use case for integrating this software into another one, outside maybe an internal corporate scenario.
Though, maybe I'll add something where you can pay to get the desktop version, similar to what Sejda does.
> trust
That's exactly right. The main attractiveness of your tool comes from the "never leaves your browser", insinuating that other similar services do send your data to a server and then who-knows has access to your sensitive data. I really like that angle. But we don't know you. We can use some tools to check that nothing is transmitted today. But who knows about the future? Maybe you change your mind? Maybe once your service becomes popular you sell it for $$$ and the new owner silently pushes things to a server "totally securely, we promise"? Or is even malicious?
> anyone can see the html/javascript
Seeing minified javascript is not the same as open source. Nobody would claim that the google doc UI is "open source".
If you open source this and it turns out as great as it seems then it can make you world famous. If you keep it closed then it will probably disappear in the vast sea of similar sevices, server-based or not (since avg Joe doesn't know the difference and doesn't care). It's your choice to make.
> Though, maybe I'll add something where you can pay to get the desktop version
Ah, thanks for your honesty here. An angle describing your project in a more bad-faith way could now be that you run beta-testing of your proprietay software through this "free" service and intend to turn it into a closed pay product once the public testing has fleshed out the main issues. That's obviously something you are free to do instead of an open source product emphasizing freedom.
> trust All fair points that you're making. I see no reason I would change my mind to send PDFs to the server, but I understand your concerns. If I'm reading in between the lines of what you're saying, that the way to alleviate these concerns is to make it open source?
I think that's a compelling argument, but to play devil's advocate if most people realistically working with PDFs aren't developers and thus wouldn't go to GitHub to host it themselves, then what would change for them to have a self-hostable option? If I released a desktop version, might the average person would see that as "private" and have any privacy concerns relieved, whether it was open sourced or not?
There is always a degree of trust you put in any company's software you use, and it's up to the company to be good stewards of that trust. If they break it, it's always bad for business anyways. But there is a point that if it was open source, those who have the desire to do so can continue using it without any concerns, which is fair.
> anyone can see the html/javascript Yes minified javascript is not the same as open source, but mine is not minified. Plain HTML, CSS and vanilla JS. So given that and since all the editing happens in the browser, the entire source code is inspectable for anyone who wants to see.
Given that the average person editing PDFs is not tech savvy, and as you said they don't really know the difference between software options, then given that what do you see as the utility of open-sourcing, from a business or even public good perspective? Genuine question.
> Though, maybe I'll add something where you can pay to get the desktop version I can see why someone would think that, but really at this point I'm figuring out what/if there is a monetization method here, and I'm not set on a particular path. I don't have any agenda to just make it free then close it off. That'd probably be a bad business decision anyways. I'm not sure if desktop is something to charge for, or if desktop and the whole thing is better to be free and open-source along with premium features that people can optionally pay for that are outside the core scope. I'm still thinking through it.
Ideally, I'll make all core features open-source while there are also some extra features people are willing to pay for. I'm just still wrestling with even just from the public good perspective, for the vast majority of people that won't host it themselves how would they benefit from open-source versus the core features just being free?
Curious if you have any response to what I've laid out here.
Appreciate your thoughtfulness!! You've given me a lot to think about.
It shows to your potential users that, even if they decided not to trust the developer anymore in the future, they will likely still be able to use your application. Everyone praised Simple Mobile Tools until the developer sold it to an ad company. But because it was open source, people were able to fork the entire suite of apps to continue using them.
There's also a lot of growth potential. draw.io likely wouldn't be integrated into so many other products if it wasn't open source. It allows them to charge money (apparently) for specific integrations, simply because everyone is already familiar with the product.
Typst is another good example. Their compiler is free and open source, but the web app is not. Certain features of their web app require a subscription, which allows them to pay the bills. But I (and many other people) wouldn't be using and recommending it if the core wasn't open source, because if Typst ever disappears, I still want to be able to compile my documents. Currently this might not matter much for your app since PDF is a universal format anyway, but as you flesh out your product, it will become more important.
It's difficult to monetise open source software, but so much more rewarding if it does work out. And your app being targeted at the general public gives you a massive advantage, since the potential market is so much larger.
I generally agree, but in this case you don't even have any meaningful identification on the site to say who created the software. I'm not sure how one can trust the creator of software if they won't even tell you who or what they are. Not even a pseudonym. There is no way to say that the person posting as philjohnson here is in fact the creator, or if the claimed copyright owner "Breeze PDF" is a legal entity that can own copyright.
As it is, with no source or identifying information, my default assumption if I happened upon this page would be that is is another one of the thousands of sites running FOSS software as a service with no added value or contribution back, but possibly also scanning every PDF it sees for bank/personal/tax/crypto information at which point it would decide to send that off to a server.
Open source isn't just about the source code being available (and when making web apps, there is often a compile step which makes the browser facing code not source code), but also about the license under which it is available.
It is in every sense of the word technically not open source.
Try pdfmini now:
https://den-run-ai.github.io/pdfmini/
Source code for pdfmini:
Here is my workflow. Have a bunch of PDFs and images I need to combine.
I go to tools.PDF24.org, Merge pdfs, then compress them, then more compress them because of size limits, then add or remove pages. Then add page numbers.
These are multiple steps.
Could we have a way of defining these terms at start, either textual or no-code-like or something where we could define stuff like
Take input, merge > compress with greyscale, Max size 1MB, add page numbers on bottom right
Or
Convert input to jpg with image size 8cm by 8cm
I know many people who simply fail at such stuff. They just throw their hands up in defeat.
Not saying we should have llms do the job but if we could have multiple actions so that people could tell the software what they have in mind.
People dont just compress PDFs, often merge and then compress.
I recently say pdfux.com but it is not as featureful as PDF24 but PDF24 crashes a lot.
# Convert images to PDF
img2pdf *.jpg -o images.pdf
# Merge PDFs
pdfunite file1.pdf file2.pdf images.pdf merged.pdf
# Compress
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook \ -dNOPAUSE -dQUIET -dBATCH -sOutputFile=compressed.pdf merged.pdf
# Remove unwanted pages (e.g., page 3)
pdftk compressed.pdf cat 1-2 4-end output final.pdf
# Add page numbers
pdfjam final.pdf --outfile final_numbered.pdf --pagecommand '{}' --landscape
And like my earlier comment, a way to define these multiple steps in a flow so that people can do multiple steps with a single file without having to learn command
I used scantailor go scan a book. That gave out tif files.
So I built a script to convert them to jpg, then merge into PDF. Then OCR and add the text layer on PDF. Then compress.
I know this for a niche automation..... web OTOH where normies reside and are scared by terminal, it wont work.
Been using pdftk for years now but im only person who can use it in my office.
Congratulations, you've managed to "compress" PDF files by rasterizing every page to JPEG, while destroying all the vector and textual information in it.
The resulting PDF is nothing like the input -- it's just a bunch of blurry JPEG images wrapped in a PDF format.
You can't search or copy the text, and trying to print it will just make a blurry mess of the text.
docker run -d -p 8080:8080 -e DOCKER_ENABLE_SECURITY=false --name stirling-pdf frooodle/s-pdf:latest
Lots of features, OP you should definitely check this out
For people who want a non web-based alternative, these days I use Xournal++ (https://xournalpp.github.io/) to do that type of edition locally.
What I am still looking for is a good way to clean scanned PDFs: split double pages, clean up text and make sure it is in lack and white, clean deformations and margin, cut and maybe rotate pages, compress the end result.
For the other issues, I haven’t found any single good tool, but I’ve stitched together things like unpaper, ghostscript and deskew ( https://github.com/galfar/deskew ).
Also, if you need OCR, hocr-tools and Google’s Document AI ocr API have worked really well for me (I tried Gemini, but you run into issues with big documents).
Yeah, you're right on that it's perception problem rather than tech. It's interesting because it's much less intuitive to inspect the code/network requests for a desktop app which on it's face seems less transparent than something on the web, but the kicker is that there is no URL that you're accessing it from so it feels safer.
I'm thinking now actually if I did a PWA? I think it has the psychological benefit of feeling of an offline desktop app (which it can function as), but is lightweight and less maintenance than an Electron app, while still having the benefit of automatically updating when I make improvements without needing to manually make updates.
Where I'm struggling on the open-source question is that in the PDF use case most of them are not developers and don't know what open source is let alone host it lol. And most businesses can probably afford to pay a nominal fee to host it themselves and modify it if they wish, which many companies offer. It would be different if the product was something like a database or code package where it's always going to be a developer using it.
While open source might actually have more "freedom" for people to modify it for free initially, in a way it can be more honest for a developer with any commercial intentions to not open source something while offering paid ways to modify the source code, as we're seeing more and more that companies start out with a very open source product that they then revert once the community has helped develop it. Not that it needs to happen that way, but with commercial aspirations one needs to be careful as something becomes popular, it becomes too tempting to take back once open-source parts.
Forgive the wall of text here, I'm thinking out loud haha. Appreciate your comment!
> in a way it can be more honest for a developer with any commercial intentions to not open source something while offering paid ways to modify the source code
I appreciate that you made your commercial intentions clear in the comments and I agree that you don't want to walk back your license as it definitely leads to backlash. I think developers (i.e. people on HN) tend to trust open-core models more where there's a clear separation between the core open-source components and a paid offering but I guess you don't have to overindex on those given the general audience of this tool.
I don't know what your ultimate monetization goal is, but in my opinion one realistic path is an one-time only payment of some reasonable amount with the full feature as opposed to subscription (I saw your Stripe link in the source).
Add a "Check for updates" button that redirects to chamgelog page in browser for extra points
Now the question is if people would be willing to pay. Perhaps it could be a nominal one-time payment to get the PWA and updates for up to a limited amount of time, or monthly amount to get updates indefinitely.
And maybe the URL accessed web version stays free with the core features, and PWA has benefits of both offline and some extra features.
Would you be willing to pay for something like this?
Also for text, different fonts is a necessary requirement (and bolding, italics, underline, etc).
Also, it seems like I can't edit text boxes after creating them... I can't even tell if I've selected the text box (an outline would be nice).
Also the confirm modal for deleting a page is realllly annoying. You should just have it automatically delete the page and create an undo feature. (Basically store the original PDF, and store all the "actions" a user makes in an array, and then undo/redo the actions to the original pdf).
Also the arrow to close the page overview on the left side of the screen is very unintuitive. Why does the entire page shift to the left? The only reason I'd use that feature is to see my centered page more clearly. On this topic, a zoom feature is super important too.
Overall, the concept of a privacy-based PDF editor sounds really cool! Just note that for users to actually make a serious switch to this, you must at least match 1/4 of the quality of other PDF services like ilovepdf.com or smallpdf.com.
Good luck!
Agree with you regarding fonts, bolding underlining etc. and having instant page deletion with undo/redo. Will definitely be adding soon.
Fixed the arrow closing the preview pane so that the page stays centered.
I plan on adding a lot more features so that it's on par with ilovepdf.com and smallpdf.com. The libraries I'm already using support many of the features they have, so it'll be easy to add them while keeping everything fully in the browser.
Thanks for the feedback!
As for having the browsers run in "offline mode" (proxy equal 127.0.0 1?)...neat but I would vote against it. My fridge just needs to keep stuff cold, my toaster should serve bread, my Internet browser should not be an app.
The "offline only" app could be a PWA where you can access if if you're offline but I could even enforce disabling network requests in the code itself. Seems like the most straightforward solution to me. Could even make updates opt-in. Would keep it lightweight and easily accessible for anyone.
What do you think of this? Would you be willing to pay for this, or are certain features you'd be willing to pay for? Curious you're thoughts.
I've found that scrolling on pdfs on a high dpi screen using the built in chromium pdf reader is extremely laggy so this has always been a must-have extension for me.
there aren't existing packages that can edit existing PDF text in the browser, but I'll do it myself sometime soon
I had a period when I worked with lots of documents. I could only find one fairly decent PDF editor which deserves to be called that way. I could use it to open any PDF and delete an existing element, or change text in an existing field. Sometimes things behaved funny, for example a text field can have each letter in a separate block, but I assume the tool did what it could within reasonable effort. It worked fine for me overall.
If the PDF hasn't been made accessible, you have to do a lot of inferencing based on the layout about how things are grouped and how they should flow if you want to be able to make meaningful edits. Not impossible (Acrobat does it), but very challenging.
It's part of the legacy of PDF as a format for presentation and print jobs, rather than typesetting.
There isn't anything off the shelf that enables editing existing text in the browser, but it's something I'll build from scratch. So you'll be able to edit existing PDF text without compromising privacy.
So if you had PDF with "Hello World" on it, you could feasibly change it to "Hello Hello", but wouldn't be able to change it to "Goodbye World" (as the glyphs for "G", "b", "y", and "e" are not included in the PDF)
Sure, you could do a bit of detective work to figure out which font it was from the glyphs or something and lookup and insert new glyphs into the PDF, but I can't imagine a generic PDF editor being capable of doing this for you.
Some editors get around this but just straight up switching the font(s) for the whole PDF, so they'll look different after saving.
You can edit text streams, which needs a decompress/recompress, messes up all the object reference offsets for the entire file, potentially adds or removes characters to the subset font, which may not be referenced by the glyphs but a number instead to intentionally break copy/paste/scrape (e.g. 'a' is not 'a' in the text stream, but a random number), etc. Assuming the text is even marked up as strings, and not individually positioned characters with nested offset co-ordinate scaling to further muddy the waters.
The fact so many people want to edit PDFs probably indicates a design flaw on Adobe's side, when considering what customers really want.
Fixes would be either using a different PDF library, or manually implementing that feature with the building blocks that pdf-lib provides.
I've updated it so that external links are also clickable when viewing the PDF in the editor. Working on getting internal links to be clickable and function as well.
Let me know if this fits what you're after
Fwiw, I do see the issue with being unable to scroll down across both Safari and Chrome.
Small request: When I have a document open, ask to prevent accidentally closing the tab.
Large request: Resizing pictures and signatures.
Ask to prevent accidentally closing the tab is a great suggestion, I just added it!
Resizing pictures and signatures is definitely something I'll add very soon.
Hooking up a good PDF editor for output is hard, but this is a nice solution.
Which features (if any) that if added would you be willing to pay for?
You would add variables in the interface, and there would be a secure sandbox in the client where you can call the API of your headless CMS, and with an sdk you could create PDF programmatically assigning the respective variables with values from your headless CMS API response. Then a button to print them. This keeps everything fully private in the browser while automating the process.
Would that work? For reference, what would you expect to pay for this if you wanted to go this route?
We have planning coming up, and I still need to see how high the priority is on this period
I'm curious where you land on this after planning, would it be okay to follow up? You can send me a note through the contact form on the BreezePDF homepage or let me know the best way to get in touch. Cheers
I'm sure some might like to modify it, though I think probably most people aren't developers and wouldn't want to.
There's no VCs or anything behind this, just me, and my costs are just a VPS to render the page, and all processing happens on the local device. So I have no reason to change any currently free features to ever not be free.
It's hard to trust your site's promise of "No uploads, 100% privacy guaranteed" when people can't audit the code.
Pen input (Apple Pencil) is quite choppy, because browsers tend to coalesce multiple pen events together, effectively reducing the pen's polling rate. You need to use PointerEvent.getCoalescedEvents: https://developer.mozilla.org/en-US/docs/Web/API/PointerEven.... Pen pressure support would also make signatures look a lot better.
Would also be nice to be able to draw anywhere you want. Right now I'm using Xournal++ for pdf annotation but its performance is lacking and I'm always looking for alternatives.
there's no way you'll ever convince the masses who use software to not call it free or appeal to software that's advertised as "free".
Fantastic work btw.
As of now I don’t plan on open sourcing. I think open sourcing software that I plan to monetize would create bad incentives. There are several companies of note that were very permissive early on with open source, and eventually after the product was built in large part by the community, they closed sourced it. I think it’s more honest to not open source it in the traditional sense, as there’s no chance of close sourcing a product that the community would have helped build for free.
What I’m thinking at the moment, to fully answer your question, is to have a downloadable version for a fair, one-time price. As of now I think this approach provides the best balance between monetization and having full trust in the software and the ability to modify the software as you wish.
When downloading the PDF, the text block is not wrapped, so it doesn't match the way it looks in the editor. Tested in Firefox (but it's the same in Chromium).
Nice work on the interface and the offline & local way it works is very welcome!
And thanks!
Thanks for the feedback, and let me know if you run into any more issues!
As much as I'd like it, we all know it can't remain "100% free and no sign-up". What's your plan to avoid enshitification?
One way it'll avoid enshitification is that I have no VCs or anything like that, it's just me. So I only answer to actual users.
My hunch is that while PDF editing is something people commonly do, most people probably don't want to pay for it, at least for basic features. My plan is to add Google Adsense, but in a way that is non-obstructive/intrusive.
Depending on feedback, I might add a paid plan for much more advanced features if there's demand. But all the features you mentioned that are missing, as well as all other basic features, will always remain free. Since all the editing happens in the browser, it's a win-win for privacy and lower resource utilization. I just have to render the webpage. It runs on a low cost VPS, so it costs me almost nothing to keep this software running. Given that, there's no current or future costs that would give any reason to remove free features.
> My plan is to add Google Adsense, but in a way that is non-obstructive/intrusive.
Please do not do Google ads.
Not only that this ruins the privacy of the users and further entrances Google's reach, but it further leads to enshitification which is what we don't want.
Perhaps maybe a small tiny sponsor banner may be better.
And yet filling out a pdf and signing it with a certificate (aka the bog standard procedure for much of modern bureaucracy) is still too much to ask for any pdf software on linux. It just doesn't exist. How?
Whenever I import PDF's into drawing programs, add something, and then export, something always seems to get messed up.
Whether it's font glyphs, or font spacing, or something to do with layer ordering.
Is it somehow filtering out referrals from this site?
https://code-industry.net/masterpdfeditor-help/certificate-m...
The real obstacle to digitally signing is bad support for Linux by the card reader vendors, as usual.
"It works on Acrobat" was something we got told a lot from clients sending us PDFs that were broken according to the official spec - we just had to deal with it.
PDFs are final produce of a rendering process. They don't have nice text or image elements you can move around as a unit. The rendering process explodes the source material into thousands of unconnected objects. Fonts are separated into their glyphs so you need to have legal access to a bunch of very expensive fonts to just to write the correct heuristics. You need good algorithms to reverse the layout and even reverse engineer entire documents to rearrange text content. It is stupidly expensive to develop in and hire for this niche. So nobody will release their very expensive heuristics in the wild.
Btw, closed-source alternatives to Acrobat exist. I like Tracker Software's editors a lot. There is also Foxit and Master PDF. The latter two work under Linux but their UI can be janky since they ship their own UI libraries.
Console. Chrome based browser. Uncaught (in promise) wc: Input document to `PDFDocument.load` is encrypted. You can use `PDFDocument.load(..., { ignoreEncryption: true })` if you wish to load the document anyways.
You can open PDF in LibreOffice Writer, just make sure to select "PDF - Portable Document Format (writer)" in the file selection dialog. This is very important, if you don't do that, the file will be opened in LibreOffice Draw instead of Writer.
Yes, lots of new features coming as well as a downloadable desktop version.
A table is definitely something I will add! Thanks for the suggestion.
Stay tuned!
Besides, most people working with PDFs aren't developers who wouldn't be able to host it locally on their own.
Thanks for this! I'll definitely add it to my bookmarks
If it's free, though, who pays for your hosting?
It runs on an very inexpensive VPS. There's no VCs or anything with this and since all processing happens on the users device, my costs won't really change at all.
Still figuring out potential monetization. Is there anything you'd pay for?
And, I’m just getting started with this, lots more features to be imminently!
BreezePDF doesn't send any data to the server, and for even further assurance, I'll be releasing the editor as a downloadable desktop version very soon.
Where is the hero who will rise to the challenge? The one who will finally rescue thousands of office and admin workers from the endless misery of XFA hell—a nightmare Adobe created and then abandoned in a pit of form chaos years ago.
Seriously, we need you. The world needs you. Be the one who ends the suffering. Be the legend.
Of course, there is no guarantee that this will remain... regularly checking network activity before uploading a private document isn't too hard
Isn't a browser for interfacing to http?