The main goal was to make a PDF viewer that is easy for developers to integrate into their websites with minimal setup, while PDF.js can be harder to customize and extend for certain use cases
For app integration, the annotations, shapes, and comments are a game changer. Once you need real PDF markup tools, your options are either building them yourself or using a subscription-based PDF editor - neither comes cheap.
I know teams that integrated Apryse, and the costs just to support basic PDF editing are eye-watering.
This may be hairsplitting, but emphasis on the handling word in that sentence. I would bet it's not so much the feature gap it's that the specification is very, very YOLO. And when any number of byte sequences happened to render as a PDF[1], then such a situation leads to a very, very diverse set of inputs that coincidentally work on some systems leading to "works on my machine" type outcomes. When your project is in the business of rendering things which happen to work in ${other system} it leads to a lot of very angry users
1: it's like the million monkeys with a million typewriters decided to go work at Adobe and they really have heard great things about mixed text and binary file formats because they are outstanding RCE and stack smashing opportunities
On the one hand, a lot of those are feature requests, not necessarily bugs. They also have more users, so they catch more edge case bugs like "Hebrew is rendered backwards" and so on.
On the other hand, PDF.js has been around for more than a decade. As it is a core component of Firefox, and viewing PDFs is an important part of name business applications, you'd think they'd have not nearly so many issues.
I know PostScript and PDFs are a nightmare, but no small part of me feels like this is yet another case of Mozilla underfunding development.
I found this and dropped their table into a sheet to get a a total of just over 2.3 billion.
Languages using right-to-left scripts https://share.google/lN5lmfjCoIW7ENvdZ
When you're not a Hebrew speaker and you don't interact with Hebrew script, and you're developing a PDF library by yourself, it's easy to not even realize that there is something about it that you've overlooked.
I don’t see dotancohene say anything about how surprising it is that that bug exists. They only say something about the judgment of it being an edge case.
Note that actual hard work here seems is done by PDFium, which is what Google bought from Foxit and then relicenced (and keep developing themselves), and which is now in Chrome.
(I don't take from your work btw, just that it's not a new PDF parser written from scratch or anything.)
Very nice! I once had a side project with a built-in PDF viewer. My first version used pdf.js, but when zooming in quickly, it felt sluggish and hard to keep the zoom focus in the right place.
So I built my own PDF viewer, this time using pdfium in C++ with Metal for rendering — here’s a quick demo: https://youtu.be/jJMhVn5yzEI
I implemented a tiling technique to balance memory usage and performance. I didn’t realize pdfium could be so performant in WebAssembly — and honestly, I actually prefer developing UI on the web compared to C++.
Honestly, yours looks even snappier than what I had, the way it’s handling zoom feels super fluid. Really impressive work! Makes me want to dig back in and see if I can match that speed.
Thank you! Smooth zooming was the main thing I focused on optimizing. I haven’t implemented text search yet, that’s a whole other rabbit hole, with challenges like stitching text objects together and handling text normalization.
My code runs natively, so users need to download a client and I have to code the rest of the ui in cpp, that’s the downside. I did consider a hybrid approach with Electron or Tauri, but dropped the idea to avoid IPC overhead and get the best possible performance.
From what I understand there are two good FOSS PDF applications for Windows. The platform that is in need of a good PDF application, where you'll acquire users, isn't Windows.
I haven’t had the chance to test annotations in Firefox yet, so thanks for pointing that out. I’ll check what’s going on there, good to know they’re working fine in Chrome.
Sounds like a mobile-vs-desktop issue, since the error mentions TouchEvent. The Firefox error fires even when just hovering the cursor over the PDF in View mode, and text is also not selectable.
While I'm here, a suggestion to add Undo/Redo; yes HN, I know I could make a PR..
Would love some more info about how redaction works. We currently use Acrobat Pro for redaction mostly because of 'trust' issues, but I'd love to replace it with a web tool. I just need to convince our CFO that it's safe.
We use pdf.js, a bunch of problems I encountered when testing and comparing (17 MB, 158 pages, many images, Windows):
* Links don’t work
* Bookmarks show up but don’t work either
* Text selection doesn’t work in FF
* Middle-clicking (to scroll) in Chrome triggers text selection
* Very slow rendering, when I scroll in pdf.js, everything looks fine. When I scroll in this, everything looks low quality and blurry for ~500-1000ms. Worse for jumping multiple pages at once, e.g. using "end", I get a white page instead of a low quality page.
* Up/Down, Page Up/Down, Home/End don’t work in FF (left/right does work)
Looks great! Diving into the docs I especially liked the idea of a headless React library so I can design my own UI and add some extra components. How difficult would it be to automatically highlight or underline certain terms in the PDF and then render a custom component when I click or hover over the term?
Very easy, this already works! In the AnnotationLayer you can add your own `selectionMenu` and render any custom component there. If you want to dive deeper, join our Discord and shoot me a message. https://discord.gg/mHHABmmuVU
Thanks for letting me know, that was related to a Firefox-specific issue I’ve just fixed. Annotations and redaction should now work in Linux + Firefox as well as Chromium.
Little note: when you switch from redaction to view with the redaction tool (red lines) active it stays active in the view mode. Impossible to scroll because it still redacts.
Good catch, I’ll fix that. On mobile, it’s intentional that scrolling is disabled while in redaction mode so you can make precise selections, but if you switch back to the view tab it should definitely exit redaction mode. Thanks for spotting it!
It would just take one additional component in your NPM package which contains all the more "internal" stuff. Just put the advanced example you have now in one component.
The example with the engine etcetera looks more like an advanced example.
It gets a developer to a quick result in their own app. If they want to go further they can nothing changes there.
A sidenote: That same though might be something with your NPM import - just one would be a better dev experience to start while I understand why you offer them separately for more advanced.
This is really valuable feedback, thank you! I agree, having a simple, ready-to-use `<EmbedPDF>` component that includes all the plugins by default would make it much easier to get started. I’ll definitely add that alongside the more advanced example.
This looks really impressive! I'm curious about the monetization strategy - how do you plan to sustain development of such a feature-rich PDF viewer while keeping it free? Are you considering enterprise features, hosting services, or other revenue streams?
Yes, all of the above. The client-side PDF viewer will remain free and MIT-licensed, but I’ll be focusing on offering PDF hosting with enterprise features like analytics, access controls etc, those will be part of the paid offering.
That’s great to hear, contributions are very welcome! If you’re interested in working on outline editing, feel free to open a discussion or draft PR and we can figure out the best way to integrate it.
KOReader user here, very happy to try something new. I use annotations very heavily, on a KDE based Debian system, on a Samsung Ultra device with the S-Pen, and with a large E-ink tablet with an EMR stylus. I use many mixed LTR and RTL text. I work with code and with documentation and with scientific articles.
If you want a demanding user with diverse use cases to test on diverse devices, you are invited to contact me. My Gmail username is the same as my HN username.
The repo appears to contain a copy of Foxit’s/Google’s pdfium along with a UI and lots of abstraction layers/examples for various JavaScript frameworks.
I’m not a JavaScript developer (perhaps there are cultural differences at play?), but in general I think it would be polite to credit the developers of the actual PDF engine.
Thank you for sharing and being so generous with the licensing. I know this might be way out of scope, but do you have any plans for a "flipbook" visualization?
We already support quite a few real PDF annotations: circle, square, polygon, polyline, highlight, underline, squiggly, strikeout,free text, stamps, and ink. Some types are still on our list, like links, form fields, sound annotations, file attachments, and 3D models. Do you happen to know what annotation type it is in your PDF? I’m curious.
In my experience links and form fields are the two above you encounter most often in the real world. The problem with forms though is that you potentially open up scripting, for better or worse. I mean you're already in Javascript, so you could handle it a lot easier than Preview on MacOS could, but it is of course worrisome that you'll be running code from an arbitrary PDF…
I wish I was still working at Apple and had my suite of nasty PDF's to test with. Some were just huge files (like a catalog for McMaster-Carr or wherever), another (a version of The Bible?) had an odd text layout across the columns on each page (for testing text selection), maybe one file was a huge single-page PDF street-map of a city (with lots and lots of rendering code and arbitrary text runs all across the map, etc.).
By ”recommend”, I meant, “nice link to send to people who want a suitable PDF reader”. As the headline puts it, “a free alternative to Adobe Acrobat PDF viewer”.
Thanks for sharing! It looks like the pdfreaders campaign has actually ended and the site is no longer updated, so I’m not sure it’s still being maintained as a resource.
I'm curious to know why you built this when the Mozilla PDF viewer exists:
https://github.com/mozilla/pdf.js
Not criticizing because there's lots of reason to build things that exist, just curious.
The main goal was to make a PDF viewer that is easy for developers to integrate into their websites with minimal setup, while PDF.js can be harder to customize and extend for certain use cases
Out of curiosity:
- Is it written from scratch? - Did you have prior experience with PDF format and rendering?
Stupid question: Do you feel LLMs can do that kind of work beyond typical SPAs with forms and CRUD?
For app integration, the annotations, shapes, and comments are a game changer. Once you need real PDF markup tools, your options are either building them yourself or using a subscription-based PDF editor - neither comes cheap.
I know teams that integrated Apryse, and the costs just to support basic PDF editing are eye-watering.
Yes, those commercial PDF SDKs charge crazy prices! Time to change that.
Cursory looks tells me that there are some different features, like annotation comments.
402 open issues, mother of God, it's a glimpse of the massive effort that is handling PDFs and all it's features.
This may be hairsplitting, but emphasis on the handling word in that sentence. I would bet it's not so much the feature gap it's that the specification is very, very YOLO. And when any number of byte sequences happened to render as a PDF[1], then such a situation leads to a very, very diverse set of inputs that coincidentally work on some systems leading to "works on my machine" type outcomes. When your project is in the business of rendering things which happen to work in ${other system} it leads to a lot of very angry users
1: it's like the million monkeys with a million typewriters decided to go work at Adobe and they really have heard great things about mixed text and binary file formats because they are outstanding RCE and stack smashing opportunities
On the one hand, a lot of those are feature requests, not necessarily bugs. They also have more users, so they catch more edge case bugs like "Hebrew is rendered backwards" and so on.
On the other hand, PDF.js has been around for more than a decade. As it is a core component of Firefox, and viewing PDFs is an important part of name business applications, you'd think they'd have not nearly so many issues.
I know PostScript and PDFs are a nightmare, but no small part of me feels like this is yet another case of Mozilla underfunding development.
In any case, there are more native speakers of right-to-left languages then there are native English speakers.
I found this and dropped their table into a sheet to get a a total of just over 2.3 billion. Languages using right-to-left scripts https://share.google/lN5lmfjCoIW7ENvdZ
When you're not a Hebrew speaker and you don't interact with Hebrew script, and you're developing a PDF library by yourself, it's easy to not even realize that there is something about it that you've overlooked.
In any case, Hebrew is handled differently from other RTL languages, hence this bug report in PDF.js: https://github.com/mozilla/pdf.js/issues/20097
Almost certainly something a smaller team would have never caught, given that a team with a massive name behind them didn't.
I don’t see dotancohene say anything about how surprising it is that that bug exists. They only say something about the judgment of it being an edge case.
I don't think there's an indication that this affects all RTL languages, just Hebrew word order in selections.
Specifically a right edge case
Nice!
Go to your link on an iPad or iPhone and open their demo document. The tap Print Preview - it only appears to work on desktop devices.
Why would you blame Mozilla for that instead of Safari? Works just fine on Android using both Chrome and Firefox.
Note that actual hard work here seems is done by PDFium, which is what Google bought from Foxit and then relicenced (and keep developing themselves), and which is now in Chrome.
(I don't take from your work btw, just that it's not a new PDF parser written from scratch or anything.)
I think it's what many (also commercial) PDF viewers are based on.
Very nice! I once had a side project with a built-in PDF viewer. My first version used pdf.js, but when zooming in quickly, it felt sluggish and hard to keep the zoom focus in the right place.
So I built my own PDF viewer, this time using pdfium in C++ with Metal for rendering — here’s a quick demo: https://youtu.be/jJMhVn5yzEI
I implemented a tiling technique to balance memory usage and performance. I didn’t realize pdfium could be so performant in WebAssembly — and honestly, I actually prefer developing UI on the web compared to C++.
Honestly, yours looks even snappier than what I had, the way it’s handling zoom feels super fluid. Really impressive work! Makes me want to dig back in and see if I can match that speed.
Thank you! Smooth zooming was the main thing I focused on optimizing. I haven’t implemented text search yet, that’s a whole other rabbit hole, with challenges like stitching text objects together and handling text normalization.
My code runs natively, so users need to download a client and I have to code the rest of the ui in cpp, that’s the downside. I did consider a hybrid approach with Electron or Tauri, but dropped the idea to avoid IPC overhead and get the best possible performance.
But what it's worth, I as a user prefer native code with no Electron.
But it will be more difficult for me to support multiple platforms, do customizations on the ui etc.
For example, I don't even own a windows pc.
I don't own a Windows PC either.
From what I understand there are two good FOSS PDF applications for Windows. The platform that is in need of a good PDF application, where you'll acquire users, isn't Windows.
Gave it a quick try. Annotations didn't work at all in Fierfox, but all annotation types (underline, highlight, etc.) worked as expected in Chrome.
I haven’t had the chance to test annotations in Firefox yet, so thanks for pointing that out. I’ll check what’s going on there, good to know they’re working fine in Chrome.
Sounds like a mobile-vs-desktop issue, since the error mentions TouchEvent. The Firefox error fires even when just hovering the cursor over the PDF in View mode, and text is also not selectable.
While I'm here, a suggestion to add Undo/Redo; yes HN, I know I could make a PR..
Thanks for pointing that out! I’ve fixed the Firefox issue. And we actually already have Undo/Redo on the annotation toolbar.
If you haven't checked yet, you'll notice:
https://developer.mozilla.org/en-US/docs/Web/API/TouchEvent#...Yep, that’s exactly the issue! I’ve fixed it so it no longer throws the TouchEvent error in Firefox. Thanks for flagging it.
Redaction doesn't seem to work in Firefox either. Otherwise looks great!
Thanks! The redaction issue in Firefox should now be fixed.
Would love some more info about how redaction works. We currently use Acrobat Pro for redaction mostly because of 'trust' issues, but I'd love to replace it with a web tool. I just need to convince our CFO that it's safe.
We use pdf.js, a bunch of problems I encountered when testing and comparing (17 MB, 158 pages, many images, Windows):
* Links don’t work
* Bookmarks show up but don’t work either
* Text selection doesn’t work in FF
* Middle-clicking (to scroll) in Chrome triggers text selection
* Very slow rendering, when I scroll in pdf.js, everything looks fine. When I scroll in this, everything looks low quality and blurry for ~500-1000ms. Worse for jumping multiple pages at once, e.g. using "end", I get a white page instead of a low quality page.
* Up/Down, Page Up/Down, Home/End don’t work in FF (left/right does work)
Looks great! Diving into the docs I especially liked the idea of a headless React library so I can design my own UI and add some extra components. How difficult would it be to automatically highlight or underline certain terms in the PDF and then render a custom component when I click or hover over the term?
Very easy, this already works! In the AnnotationLayer you can add your own `selectionMenu` and render any custom component there. If you want to dive deeper, join our Discord and shoot me a message. https://discord.gg/mHHABmmuVU
Unfortunately, the Demo doesn't seem to work with my combination of Linux + Firefox. I cannot get any of the annotation/redaction tools to work.
It seems to work with Chromium on the same machine.
Thanks for letting me know, that was related to a Firefox-specific issue I’ve just fixed. Annotations and redaction should now work in Linux + Firefox as well as Chromium.
Seems to work great!
Little note: when you switch from redaction to view with the redaction tool (red lines) active it stays active in the view mode. Impossible to scroll because it still redacts.
Refresh fixes it.
Good catch, I’ll fix that. On mobile, it’s intentional that scrolling is disabled while in redaction mode so you can make precise selections, but if you switch back to the view tab it should definitely exit redaction mode. Thanks for spotting it!
Not sure if it matches your vision but I just took a look at the react example:
https://www.embedpdf.com/docs/react/getting-started
I would suggest that you start with a more simple example. like:
<EmbedPDF url={https://snippet.embedpdf.com/ebook.pdf}/>
It would just take one additional component in your NPM package which contains all the more "internal" stuff. Just put the advanced example you have now in one component.
The example with the engine etcetera looks more like an advanced example.
It gets a developer to a quick result in their own app. If they want to go further they can nothing changes there.
A sidenote: That same though might be something with your NPM import - just one would be a better dev experience to start while I understand why you offer them separately for more advanced.
This is really valuable feedback, thank you! I agree, having a simple, ready-to-use `<EmbedPDF>` component that includes all the plugins by default would make it much easier to get started. I’ll definitely add that alongside the more advanced example.
Nice work! The composable design is really better than something like viewer mode or annotation mode
This is amazing. Unlike Acrobat Reader, this actually made me want to read a pdf. And the UI looks super professional.
That means a lot to me, thank you!
This looks really impressive! I'm curious about the monetization strategy - how do you plan to sustain development of such a feature-rich PDF viewer while keeping it free? Are you considering enterprise features, hosting services, or other revenue streams?
Yes, all of the above. The client-side PDF viewer will remain free and MIT-licensed, but I’ll be focusing on offering PDF hosting with enterprise features like analytics, access controls etc, those will be part of the paid offering.
Does it support editing the embedded outline (annotations)?
Probably the number one missing feature of PDF editors/viewers. Miss it everytime someone sends me a PDF without outline.
It doesn’t support editing outlines yet, but it’s definitely possible and something I plan to look into. I don’t think it should be too hard to add.
Would be awesome! The only free PDF editor that works on linux to support that currently is PDF4QT. If you accept PRs I'd be happy to contribute too.
That’s great to hear, contributions are very welcome! If you’re interested in working on outline editing, feel free to open a discussion or draft PR and we can figure out the best way to integrate it.
This is really great. The speed is great, and I've had issues with Mozilla PDF viewer recently. (Printing fails for some unknown reason.)
But I assumed it was also a standalone app? Could this be used as a standalone app in some fashion?
Thanks! For now we’re only building a web app, but depending on demand we’d love to build native apps for Android, iOS, and desktop OSs as well.
KOReader user here, very happy to try something new. I use annotations very heavily, on a KDE based Debian system, on a Samsung Ultra device with the S-Pen, and with a large E-ink tablet with an EMR stylus. I use many mixed LTR and RTL text. I work with code and with documentation and with scientific articles.
If you want a demanding user with diverse use cases to test on diverse devices, you are invited to contact me. My Gmail username is the same as my HN username.
The repo appears to contain a copy of Foxit’s/Google’s pdfium along with a UI and lots of abstraction layers/examples for various JavaScript frameworks.
I’m not a JavaScript developer (perhaps there are cultural differences at play?), but in general I think it would be polite to credit the developers of the actual PDF engine.
The repo is marked with the pdfjs and pdfium topics so there is that.
Beyond that, powered by... and similar make sense if the library/engine allows or encourages the behavior.
Absolutely, and I agree, credit is important. I have a whole section in the docs about PDFium and its origins with Foxit/Google: https://www.embedpdf.com/docs/pdfium/introduction.
That’s neat.
I would also mention it in the README.md.
Thank you for sharing and being so generous with the licensing. I know this might be way out of scope, but do you have any plans for a "flipbook" visualization?
Not on the roadmap yet, but I’d definitely be open to adding it if more people are interested.
Requiring a whatng cartel web engine? Then, nothing to be proud of, mate.
But that's a bravery to deal with the brain damaged PDF file format.
Haha fair, but PDFium's under Apache 2.0, so at least the “cartel” in this case is about as open-license as it gets.
Huh?
This is not related to the LICENSE, it is related to the technical dependency on a whatng cartel web engine (geeko/blink/webkit).
I tried a random PDF that includes an annotation, but the annotation didn't show up. I assume the annotations this supports are no real annotations?
We already support quite a few real PDF annotations: circle, square, polygon, polyline, highlight, underline, squiggly, strikeout,free text, stamps, and ink. Some types are still on our list, like links, form fields, sound annotations, file attachments, and 3D models. Do you happen to know what annotation type it is in your PDF? I’m curious.
In my experience links and form fields are the two above you encounter most often in the real world. The problem with forms though is that you potentially open up scripting, for better or worse. I mean you're already in Javascript, so you could handle it a lot easier than Preview on MacOS could, but it is of course worrisome that you'll be running code from an arbitrary PDF…
I wish I was still working at Apple and had my suite of nasty PDF's to test with. Some were just huge files (like a catalog for McMaster-Carr or wherever), another (a version of The Bible?) had an odd text layout across the columns on each page (for testing text selection), maybe one file was a huge single-page PDF street-map of a city (with lots and lots of rendering code and arbitrary text runs all across the map, etc.).
Seems to work pretty well on Firefox for Android. Very impressive work!
Thanks! Glad to hear it’s working well on Firefox for Android.
Is selecting text in the PDF supported? I can’t get that to work in iOS Safari.
Text selection broken on Mac OS Safari as well. Worked in Chrome on Mac OS.
Very nice! Thanks for sharing. How long are you working on that ?
Thanks! I’ve been working on it for about 7 months now.
MIT license is generous. Good for you, and thanks!
The underlying PDFium is Apache 2.0 though, and it looks to me that the present project doesn’t currently comply with https://www.apache.org/licenses/LICENSE-2.0#redistribution for that dependency.
Good point, you’re right that PDFium is Apache 2.0. I’ve updated the project to comply with the redistribution requirements in this PR: https://github.com/embedpdf/embed-pdf-viewer/pull/80/files. Thanks for flagging it!
Thanks! I wanted to make it as easy as possible for people to use, tweak, and build on top of it, so MIT felt like the right choice.
The mobile site works well. Quite fast and snappy
Thanks! Glad to hear it’s running smoothly on mobile, the rendering on iOS in particular feels really fast.
Great project.
Would be wonderful to have PKCS#11 and PKCS#12.
Thanks! Signing is a high priority for us, and PKCS#11 and PKCS#12 support are definitely on our radar.
Very cool. Having something to fill forms and sign them that works and isn't Acroread would be even more awesome than you project already is!
Nitpick, but Viewer is free and always has been. You're building a free alternative to Acrobat.
If you want traction, I suggest you package a .dmg file for Mac users.
the best solution is simply to not use PDF.
> Show HN: I built a free alternative to Adobe Acrobat PDF viewer
It needs a web browser so no alternative to Adobe PDF viewer.
I’d much rather recommend <https://pdfreaders.org/>, so people can choose depending on their situation. Does this project belong there, too?
What are you recommending? That's a list of other open PDF readers, which mostly serve purposes very different from what the author here has done.
By ”recommend”, I meant, “nice link to send to people who want a suitable PDF reader”. As the headline puts it, “a free alternative to Adobe Acrobat PDF viewer”.
Thanks for sharing! It looks like the pdfreaders campaign has actually ended and the site is no longer updated, so I’m not sure it’s still being maintained as a resource.