Firecrawl умеет вытаскивать текст не только с веб-страниц, но и напрямую из PDF-файлов, включая таблицы и многоколоночную верстку. Для этого не нужен отдельный инструмент: PDF отправляется в тот же API, что и обычный URL. На выходе LLM получает чистый markdown, готовый для промпта или векторной базы.
В 2026 году Firecrawl парсит PDF через единый API с веб-страницами: движок Fire-PDF на Rust обрабатывает страницу быстрее чем за 400 мс. С текстовыми PDF работает надежно, со сканами нужен OCR и качество падает, а сложная верстка иногда путает порядок текста. Разбираем все три случая и когда стоит взять специализированный парсер.
Как Firecrawl обрабатывает PDF и веб-страницы через один API?
Firecrawl не делит источники на "сайты" и "документы". Ссылка на PDF или сам файл проходят через тот же /scrape или /parse, что и HTML-страница, и на выходе получается одинаковый markdown.
Firecrawl отправляет PDF через тот же пайплайн, что и обычную веб-страницу, и возвращает markdown, JSON или превью в одном ответе. Такой единый формат экономит время на архитектуре: не приходится держать два разных обработчика под HTML и под документы. По документации Parse, эндпоинт принимает PDF, DOCX, XLSX и еще несколько форматов, и все они превращаются в один и тот же вид markdown.
Для RAG-системы это удобно вдвойне. База знаний часто собрана из разнородных кусков: часть контента лежит на сайтах, часть в виде договоров и отчетов в PDF. Если оба типа источников проходят через один API, векторная база получает одинаковую структуру данных на входе, и не нужно писать отдельный код под каждый тип файла.
Мы разбирали общую механику работы Firecrawl с сайтами в обзоре инструмента. PDF встроен в ту же логику, просто с дополнительным шагом классификации страниц перед извлечением текста.

Насколько надежно Firecrawl парсит обычный текстовый PDF?
Если в PDF текст хранится как текст, а не как картинка, извлечение работает стабильно: сохраняются заголовки, списки, таблицы и порядок чтения.
По данным разработчиков, движок pdf-inspector читает внутреннюю структуру файла (шрифты, текстовые операторы, покрытие изображениями) за миллисекунды и решает по каждой странице, нужен ли OCR. На открытом бенчмарке из 200 документов инструмент показал результат 0,875 за 0,47 секунды на весь корпус. Это и есть база надежности для текстовых PDF.
На практике это означает следующее: научные статьи, договоры, отчеты в PDF, экспортированные из Word или сверстанные типографским способом, парсятся почти без потерь. Заголовки остаются заголовками, списки списками, а не превращаются в один слипшийся абзац. Для вайбкодера, который строит RAG по корпоративным документам, это самый частый и самый благодарный случай.

Что происходит со сканированным PDF без текстового слоя?
Скан - это картинка, а не текст, поэтому Firecrawl сначала запускает OCR и только потом извлекает markdown. Качество результата заметно ниже, чем на текстовых документах.
Если страница на самом деле фотография или скан без текстового слоя, движок Fire-PDF классифицирует ее как страницу без текста и направляет через GPU-based OCR, в среднем меньше 400 мс на страницу. Здесь честно стоит предупредить: качество распознавания зависит от исходника. Плохое качество скана, рукописные пометки, наклонная съемка на телефон - все это снижает точность.
Для проекта с большим числом сканов имеет смысл заранее проверить хотя бы 10-15 документов вручную и сравнить результат с оригиналом. Если процент ошибок в ключевых цифрах или именах слишком высок, дешевле один раз доработать пайплайн предобработки изображений, чем потом чистить векторную базу от галлюцинаций LLM, которая опиралась на кривой OCR.
Почему сложная многоколоночная верстка иногда путает порядок текста?
Научные статьи с двумя колонками на странице - самый частый источник перепутанного порядка текста при автоматическом извлечении.
Reading order, то есть порядок чтения, предсказывается нейросетевой моделью прямо во время парсинга. На простой одноколоночной странице это почти не задача, но на двух-трех колонках с врезками и сносками алгоритм иногда собирает абзацы не в том порядке, в котором их читал бы человек.
На практике баг выглядит так: предложение из левой колонки внезапно склеивается с предложением из правой, и смысл теряется. Перед массовой автоматизацией процесса стоит прогнать через парсер 5-10 реальных документов вашего типа верстки и вручную свериться с markdown на выходе. Если ошибок мало, можно запускать пайплайн на весь корпус. Если много, помогает либо предварительное разбиение страницы на колонки, либо переход на специализированный инструмент.

Как Firecrawl извлекает таблицы и формулы из PDF?
Таблицы конвертируются в markdown-таблицы с сохранением строк и столбцов, а формулы сохраняются в формате LaTeX, что удобно для последующей работы LLM.
Для RAG-пайплайна это критично: если таблица с ценами или условиями договора превращается в кашу из текста без структуры, модель на этапе ответа просто не сможет сослаться на конкретную ячейку. Firecrawl размечает layout по каждой странице отдельно и указывает, сколько страниц документа содержат таблицы, а сколько многоколоночный текст, так что можно заранее оценить сложность корпуса до полной обработки.
Ниже - как выглядят три сценария парсинга PDF в сравнении.
| Тип PDF | Что происходит при парсинге | Надежность результата |
|---|---|---|
| Текстовый PDF (Word-экспорт, типографская верстка) | Текст читается напрямую, OCR не запускается | Высокая, структура и таблицы сохраняются |
| Скан без текстового слоя | Автоматически запускается OCR | Средняя, зависит от качества скана |
| Многоколоночная верстка (научные статьи, журналы) | Порядок чтения предсказывается нейросетью | Требует проверки, возможны перепутанные абзацы |

Когда лучше выбрать специализированный PDF-парсер вместо Firecrawl?
Если PDF - это основной и единственный тип источника в проекте, а не часть смеси из веб-страниц и документов, специализированный парсер иногда точнее на действительно сложных сканах и таблицах.
Firecrawl оптимален, когда PDF - лишь часть общего разнородного потока данных вместе с обычными сайтами: не приходится держать два пайплайна и два формата вывода. Но если весь проект строится вокруг тысяч отсканированных архивных документов или узкоспециализированных научных PDF с формулами и сложной версткой, узкоспециализированные инструменты вроде Docling, Marker-PDF или LlamaParse могут дать чуть выше точность именно на этом типе контента, ценой более сложной интеграции.
| Инструмент | Сильная сторона | Когда выбрать |
|---|---|---|
| Firecrawl (Parse / Fire-PDF) | Единый API для PDF и веб-страниц, быстрая обработка | Смешанные источники: сайты и документы вместе |
| Docling | Глубокая работа с научной версткой и формулами | Проект целиком построен на PDF-корпусе |
| Marker-PDF | Открытый код, гибкая настройка пайплайна | Нужен полный контроль над каждым шагом парсинга |
| LlamaParse | Интеграция с LlamaIndex из коробки | RAG уже собран на стеке LlamaIndex |
Лиза: «Раньше руками разбирала по 15-20 видео на одну статью. Написала скрипт в Google Таблицах: вставляешь ссылки, дальше транскрибация и разбор по 15 критериям идут сами. Было 4 часа, стало 5,5 минуты. С парсингом документов работает тот же принцип: один раз собираешь пайплайн, дальше он просто работает.»
Если строите RAG по внутренней базе знаний компании, разница между этими подходами разобрана подробнее в статье про RAG для корпоративной базы знаний. А для тех, кто только начинает разбираться в теме, есть простое объяснение RAG для вайбкодеров.

Глоссарий
- RAG (Retrieval-Augmented Generation) - подход, при котором LLM перед ответом ищет релевантные фрагменты в базе документов и опирается на них.
- OCR (Optical Character Recognition) - технология распознавания текста на изображении или скане.
- Reading order - порядок чтения текста на странице, важен при многоколоночной верстке.
- Layout extraction - разметка структуры документа: где заголовки, таблицы, колонки.
- Markdown - легкий текстовый формат разметки, который LLM понимает лучше, чем сырой HTML или PDF.
- Текстовый слой PDF - встроенный в файл настоящий текст, в отличие от картинки страницы.

Часто задаваемые вопросы
Firecrawl парсит PDF так же, как веб-страницы?
Да. Ссылку на PDF или сам файл можно отправить в тот же endpoint, что и обычный URL, и получить такой же markdown на выходе, без отдельного кода под документы.
Нужен ли OCR для парсинга PDF в Firecrawl?
Для текстовых PDF нет, движок читает встроенный текстовый слой напрямую. Для сканов OCR запускается автоматически, но качество результата зависит от исходника.
Сохраняются ли таблицы при извлечении текста из PDF?
Да, таблицы переводятся в markdown-таблицы с сохранением строк и столбцов, формулы сохраняются в LaTeX.
Можно ли парсить PDF, защищенный паролем?
Да, при условии что пароль передан вместе с запросом на парсинг.
Ломает ли многоколоночная верстка результат парсинга?
Иногда. На страницах с двумя-тремя колонками алгоритм предсказания порядка чтения может ошибиться, поэтому перед массовым запуском стоит проверить выборку документов вручную.
Когда стоит выбрать специализированный PDF-парсер вместо Firecrawl?
Когда PDF - единственный или основной тип источника в проекте, а не часть смеси с веб-страницами, и нужна максимальная точность на сложных сканах.
Сколько страниц PDF можно распарсить бесплатно?
Бесплатный конвертер Firecrawl обрабатывает первые 10 страниц любого публичного PDF без регистрации, для объемной обработки нужен платный доступ к API.
Разобраться, какой стек парсинга и RAG подойдет именно вашему проекту, можно на консультации с Максимом. А сравнить IDE и AI-инструменты, которые пригодятся для сборки такого пайплайна, - в каталоге AI-инструментов VibeCoderz.
Обновлено: сентябрь 2026.