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
Para a etapa de OCR especificamente, você pode pular a configuração do pdftoppm + extensão Docker e usar o nó SealDoc em vez disso. Ele executa ocrmypdf + Tesseract internamente em uma instância SealDoc auto-hospedada, portanto nada sai de sua infraestrutura.
Configuração do nó em n8n:
Resource: Job
Operation: Create
Enable: Run OCR (ativar)
OCR Languages: eng (ou eng+deu, nld+fra, etc.)
O nó retorna o texto extraído, que você conecta diretamente ao seu nó Ollama para resumo ou estruturação. O SealDoc gerencia a conversão de imagem e o processamento do Tesseract, para que você não precise de nós Execute Command ou de uma imagem Docker personalizada.
Opa, isso soa interessante. Porém, como posso ver, fica pago quando você atinge um certo tamanho. Além disso, não consigo acessar o site porque depois de inserir as informações da minha empresa, fico preso em um loop infinito.
Oi Leon, o loop infinito era um bug real. Afetou algumas pessoas hoje e a gente deployou um fix agora mesmo. Faça um hard-refresh ou limpe os dados do site para app.sealdoc.eu se ainda estiver mostrando a página antiga.
Sobre preços: o plano gratuito cobre 50 documentos/mês com OCR completo e extração de texto, o que deve ser suficiente para avaliar se encaixa no seu fluxo de trabalho. Os planos pagos entram em jogo se você precisar de volume maior ou retenção além de 24h.
Muito obrigado por todas as ideias e sugestões até agora. Infelizmente, ainda tenho o mesmo problema e continuo procurando uma solução.
Meu objetivo é extrair texto de arquivos PDF digitalizados que não contêm uma camada de texto. Se os arquivos forem arquivos de imagem comuns em vez de PDFs, posso simplesmente usar o nó “Analyze Image” (Analisar Imagem) do Ollama e obter resultados bastante utilizáveis. No entanto, isso obviamente não funciona diretamente com arquivos PDF.
Realmente não há forma de processar PDFs digitalizados diretamente em um fluxo de trabalho n8n e extrair o texto deles?
Toda a configuração deve continuar funcionando totalmente localmente e preferencialmente permanecer completamente gratuita.
Fico feliz em receber mais sugestões — exemplos de fluxos de trabalho ou trechos de código também seriam muito bem-vindos
não sei se já deram essa resposta, por favor me avise caso sim, porque a thread está grande demais.
para pdfs escaneados, o Extract from PDF não resolve porque não existe camada de texto, a gente precisa converter cada página em imagem e aplicar OCR. tente instalar poppler-utils no container , use via Execute Command para gerar PNGs e depois enviar essas imagens ao Ollama.
A doc mostra que o n8n tem operação para extrair conteúdo de PDF, mas isso é extração de conteúdo existente no arquivo, não OCR de imagem escaneada.
A doc explica que, se você precisa rodar comandos/binários dentro do n8n Docker, deve criar uma imagem baseada na imagem oficial e instalar os pacotes necessários.
A doc do pdftoppm diz que ele converte arquivos PDF em imagens, gerando uma imagem por página.
De alguma forma, toda vez que tento adicionar algo novo ao workflow que poderia resolver meu principal problema de OCR, acabo criando ainda mais problemas primeiro
Já instalei tanto pdftoppm quanto ImageMagick dentro do meu container Docker e tentei resolver o problema do PDF digitalizado com eles. Mas agora estou travado no nó Read/Write Files from Disk porque sempre recebo o seguinte erro:
The file "/temp-files/input" is not writable.
Já procurei no fórum e no Google por esse erro específico, mas não consegui encontrar uma solução que funcionasse, então pensei em perguntar aqui de novo.
O que estou tentando conseguir é na verdade bem simples:
Quero apenas converter um PDF digitalizado em arquivos de imagem dentro do workflow usando pdftoppm ou ImageMagick, para que eu possa enviar essas imagens para o nó Ollama para reconhecimento de OCR.
Até agora não encontrei outra solução totalmente local e gratuita que funcione de forma confiável para PDFs digitalizados.
Já testei Tesseract também, mas honestamente a qualidade do OCR foi bem ruim no meu caso.
Então se alguém tiver uma ideia do que poderia estar causando o erro de gravação ou como lidar adequadamente com arquivos temporários em Docker/n8n, eu realmente agradeceria a ajuda ^^
O caminho /temp-files/input é o problema - esse diretório não existe ou não é gravável no container Docker do n8n por padrão. Mude para /tmp, que é sempre gravável em containers: use /tmp/page-%03d.png como o caminho de saída no nó Execute Command.
Além disso, para que o nó Read/Write Files acesse /tmp, certifique-se de que a variável de ambiente N8N_RESTRICT_FILE_ACCESS_TO está configurada para incluir /tmp na sua config Docker, ou não está definida (ela restringe o acesso a arquivos se estiver definida). Se você estiver em uma versão recente do n8n, verifique se o caminho no nó Read/Write Files corresponde exatamente ao que pdftoppm ou ImageMagick gera - o padrão %03d gera page-001.png, page-002.png, etc., então você os leria de volta fazendo um loop por esse padrão.
Você pode usar o nó Execute Command no n8n para executar o Tesseract OCR localmente. Basta instalar o Tesseract e o Poppler no seu host n8n, depois encadear como: Read Binary File → Execute Command (OCR) → HTTP Request para Ollama. Para PDFs com várias páginas, OCRmyPDF em um sidecar Docker é mais limpo, e você pode chamá-lo por meio do nó HTTP Request sem tocar no host n8n. Tudo permanece 100% local.
I’m still learning, but I’d really appreciate any guidance or example workflows!
