hi @Leon22
I would use a fully local OCR service exposed over HTTP or running in a separate container and call it from n8n before sending the text to Ollama, because with scanned PDFs the text must first be generated by a dedicated OCR step outside the standard PDF extraction flow.
Hey! Since you already have Ollama running locally, easiest route is just convert your PDF pages to images with pdftoppm in an Execute Command node and then send those to an Ollama vision model like llama3.2-vision for the OCR, taht way you skip needing any extra services.
Hey, thanks a lot for your help — really appreciate it!
I have a few follow-up questions because I’m still pretty new to n8n and this setup:
From what I understand, I should use pdftoppm to convert PDF pages into images first. I’ve read that it’s part of the poppler-utils package — is that correct?
How exactly would I install that in my setup?
do I need to install poppler-utils with docker ?
If it’s inside Docker, would I extend the n8n image or run a separate container?
Also, once it’s installed:
How do I actually call pdftoppm from within n8n?
Would I use an Execute Command node for that?
Or is there a better approach (e.g. Code node, external service, etc.)?
Sorry if these are basic questions I’m still learning, but I’d really appreciate any guidance or example workflows!
@Leon22 yeah poppler-utils is correct. If you’re using the official n8n docker image just extend it with a custom Dockerfile like FROM n8nio/n8n:latest then USER root and RUN apk add --no-cache poppler-utils then USER node, rebuild (e.g. docker build -t n8n-ocr .) and point your compose/run at the new tag. The n8n image is Alpine-based so it’s apk not apt.
To add to @achamm’s spot-on Docker instructions, to answer your second question: Yes, you will use the Execute Command node to run pdftoppm.
The tricky part for beginners is that CLI tools expect physical files on the disk, while n8n holds your PDF in memory as binary data. The standard pattern for this is:
Use a Read/Write Files from Disk node to save your PDF binary to a temporary path like /tmp/input.pdf.
Use the Execute Command node to run: pdftoppm -png /tmp/input.pdf /tmp/output
Use another Read/Write Files from Disk node to read the generated /tmp/output-1.png back into n8n as binary data so you can send it to your Ollama node.
Just don’t forget to add a final Execute Command node to rm those temp files afterward, or your Docker container will eventually run out of space!
Great approach with pdftoppm + Ollama! One thing to add: if your PDFs are multi-page, you might want to loop through each generated image file and pass them to Ollama one by one, then merge the text outputs at the end. I’ve done similar pipelines in n8n using a Split In Batches node after the Execute Command step. Also worth noting: make sure your Ollama model (like llava or minicpm-v) is actually good at OCR - some vision models are better than others for dense text extraction.
Spot on about the multi-page handling! Throwing a massive PDF at a vision model all at once is a guaranteed way to hit context limits or crash the instance.
If anyone implements this approach using the Loop node (formerly Split In Batches), I highly recommend adding a short Wait node or configuring automatic retries on the Ollama request step. If n8n fires 20 heavy image processing requests at your local Ollama container simultaneously, the container can easily choke and drop requests, leaving you with missing pages in your final merged text. Excellent call on minicpm-v as well, it’s a beast for OCR!
Spot on! Batch-testing the models against the actual PDF artifacts is definitely the right move. I’ve noticed Llava can sometimes hallucinate on dense tables where minicpm-v stays a bit more strict, but it really does depend on the scan quality. Appreciate the shoutout!
For local PDF OCR in n8n, the most reliable approach I’ve found is using a vision-capable model in Ollama (like llava or llava-llama3) combined with converting PDF pages to images first using the Extract PDF node, then sending each page image to Ollama for text extraction.
The key is to set raw: true in the Ollama options to prevent the model from adding reasoning artifacts to the output. You then collect the extracted text across pages and concatenate.
This keeps everything local without needing Tesseract or external OCR services. Works well for structured documents, though accuracy drops on low-quality scans.
Thanks a lot for the detailed explanation — that’s actually exactly the approach I’d like to use
The only issue I’m running into is with scanned PDFs. When I pass them into the Extract from PDF node, it doesn’t return any text at all (the output is basically empty), which I assume is expected since there’s no embedded text layer.
Right now my workaround is:
convert the PDF pages into images (PNG)
then send those images to an Ollama OCR model (I’m using qwen2.5vl:7b)
That part actually works really well for me.
However, I’d prefer to handle the PDF → image conversion directly inside the n8n workflow, instead of doing it externally beforehand.
So my questions would be:
Is there a recommended way in n8n to convert PDF pages to images (PNG/JPG) within the workflow?
Or is there any way to make the Extract from PDF node handle scanned PDFs that I might be missing?
Appreciate any tips — would love to keep everything fully local and inside n8n if possible
Pour l’étape OCR spécifiquement, vous pouvez ignorer la configuration pdftoppm + extension Docker et utiliser le nœud SealDoc à la place. Il exécute ocrmypdf + Tesseract en interne sur une instance SealDoc auto-hébergée, donc rien ne quitte votre infrastructure.
Configuration du nœud dans n8n :
Resource : Job
Operation : Create
Enable : Run OCR (activer)
OCR Languages : eng (ou eng+deu, nld+fra, etc.)
Le nœud génère le texte extrait, que vous reliez ensuite directement à votre nœud Ollama pour résumer ou structurer. SealDoc gère la conversion d’image et le passage Tesseract, vous n’avez donc pas besoin de nœuds Execute Command ou d’une image Docker personnalisée.
Hé, ça semble intéressant. Cependant, comme je peux le voir, ça devient payant une fois que tu atteins une certaine taille. De plus, je ne peux pas accéder au site web parce qu’après avoir entré les informations de mon entreprise, je me retrouve bloqué dans une boucle sans fin.
Salut Leon, la boucle infinie était un vrai bug. Ça a touché quelques utilisateurs aujourd’hui et on vient de pousser un correctif. Fais un hard-refresh ou vide les données du site pour app.sealdoc.eu si tu vois encore l’ancienne page.
Sur la tarification : l’offre gratuite couvre 50 documents/mois avec OCR et extraction de texte complètes, ce qui devrait suffire pour évaluer si ça s’adapte à ton workflow. Les offres payantes commencent si tu as besoin de volumes plus élevés ou d’une conservation au-delà de 24h.
Merci beaucoup pour toutes les idées et suggestions jusqu’à présent. Malheureusement, j’ai toujours le même problème et je continue à chercher une solution.
Mon objectif est d’extraire du texte à partir de fichiers PDF numérisés qui ne contiennent pas de couche de texte. Si les fichiers sont des fichiers image ordinaires au lieu de PDF, je peux simplement utiliser le nœud « Analyze Image » d’Ollama et obtenir des résultats assez utilisables. Cependant, cela ne fonctionne évidemment pas directement avec les fichiers PDF.
N’y a-t-il vraiment aucun moyen de traiter les PDF numérisés directement dans un flux de travail n8n et d’en extraire le texte ?
Toute la configuration devrait continuer à s’exécuter entièrement en local et rester de préférence entièrement gratuite.
Je suis toujours heureux de recevoir d’autres suggestions — des exemples de flux de travail ou des extraits de code seraient également très appréciés
I don’t know if you’ve already been given this answer, please let me know if so, because the thread is too long.
for scanned PDFs, Extract from PDF doesn’t work because there’s no text layer, we need to convert each page to an image and apply OCR. try installing poppler-utils in the container, use it via Execute Command to generate PNGs and then send those images to Ollama.
The doc shows that n8n has an operation to extract content from PDF, but that’s extraction of content already in the file, not OCR of scanned images.
The doc explains that if you need to run commands/binaries inside n8n Docker, you should create an image based on the official image and install the necessary packages.
The pdftoppm doc says it converts PDF files to images, generating one image per page.
D’une façon ou d’une autre, chaque fois que j’essaie d’ajouter quelque chose de nouveau au workflow qui pourrait résoudre mon problème OCR principal, je finis par créer encore plus de problèmes d’abord
J’ai déjà installé à la fois pdftoppm et ImageMagick dans mon conteneur Docker et j’ai essayé de résoudre le problème des PDF scannés avec eux. Mais maintenant je suis bloqué au nœud Read/Write Files from Disk parce que j’obtiens toujours l’erreur suivante :
The file "/temp-files/input" is not writable.
J’ai déjà cherché sur le forum et Google cette erreur spécifique mais je n’ai pas vraiment trouvé de solution qui fonctionne, alors j’ai pensé redemander ici.
Ce que j’essaie de faire est en fait assez simple :
Je veux juste convertir un PDF scanné en fichiers image dans le workflow en utilisant soit pdftoppm soit ImageMagick, pour pouvoir ensuite envoyer ces images au nœud Ollama pour la reconnaissance OCR.
Jusqu’à présent, je n’ai pas trouvé d’autre solution entièrement locale et gratuite qui fonctionne de manière fiable pour les PDF scannés.
J’ai déjà testé Tesseract aussi, mais honnêtement la qualité OCR était assez mauvaise dans mon cas.
Donc si quelqu’un a une idée de ce qui pourrait causer l’erreur writable ou comment gérer correctement les fichiers temporaires dans Docker/n8n, je l’apprécierais vraiment ^^
Le chemin /temp-files/input est le problème - ce répertoire n’existe pas ou n’est pas accessible en écriture dans le conteneur Docker n8n par défaut. Basculez plutôt vers /tmp, qui est toujours accessible en écriture dans les conteneurs : utilisez /tmp/page-%03d.png comme chemin de sortie dans le nœud Execute Command.
Aussi, pour que le nœud Read/Write Files puisse accéder à /tmp, assurez-vous que la variable d’environnement N8N_RESTRICT_FILE_ACCESS_TO est définie pour inclure /tmp dans votre configuration Docker, ou n’est pas définie du tout (elle restreint l’accès aux fichiers si elle est définie). Si vous utilisez une version récente de n8n, vérifiez que le chemin dans le nœud Read/Write Files correspond exactement à ce que pdftoppm ou ImageMagick produit - le motif %03d génère page-001.png, page-002.png, etc., donc vous les reliriez en boucle à travers ce motif.
Vous pouvez utiliser le nœud Execute Command dans n8n pour exécuter Tesseract OCR localement. Il suffit d’installer Tesseract et Poppler sur votre hôte n8n, puis de le chaîner comme : Read Binary File → Execute Command (OCR) → HTTP Request vers Ollama. Pour les PDF multi-pages, OCRmyPDF dans un conteneur Docker sidecar est plus propre, et vous pouvez l’appeler via le nœud HTTP Request sans toucher à l’hôte n8n. Tout reste 100 % local.
I’m still learning, but I’d really appreciate any guidance or example workflows!
