LinkedIn resume parser: the three exports, and what each gives you

Published 20 September 2026

LinkedIn resume parser: what LinkedIn actually gives you, and how to get JSON out of it

If you are looking for a LinkedIn resume parser, the first thing to settle is which LinkedIn export you are parsing, because there are three and they are not interchangeable. LinkedIn has no public endpoint that hands a third party a member's profile, so every tool in this category starts from a file the member themselves produced: a profile PDF, a data archive, or — in some countries only — a portability API response. Each has a different shape, a different limit, and a different amount of work between it and typed JSON. All LinkedIn facts below were read from LinkedIn's own help pages as of September 2026.

We build ResumeJSON, a per-parse resume and CV parsing API, so read the last section as written by an interested party. The LinkedIn facts in the first half are checkable against the help pages linked beside them, and they are the part that decides your design.

The three exports, compared

The practical consequence: if you are building a product that ingests other people's profiles, the PDF is the only route. The archive and the portability API are self-service exports of your own account, so they can never be the input path for a job board, an ATS or a candidate-matching tool taking uploads from strangers.

Save to PDF — the one that behaves like a resume

This is the export most people mean by "LinkedIn resume". From the introduction section of a profile on desktop, More (or Resources) → Save to PDF produces a PDF laid out like a CV: headline, about, experience with dates, education, skills, certifications.

Three constraints from LinkedIn's own Save a profile as a PDF page are worth knowing before you build on it:

• It is desktop only. LinkedIn states the feature "is not available on the LinkedIn mobile app". A mobile-first upload flow cannot ask the user to produce one on the spot.
• It is English only. LinkedIn's note is explicit: "Profiles must be in English, and the member's language setting must also be English for the feature to work correctly. If the member's language is set to any language other than English, translation mismatches may occur, resulting in improper PDF rendering." A multilingual candidate pool will produce files with mixed or mis-rendered labels.
• There is a monthly cap. "You're limited to 200 PDF downloads per month when saving LinkedIn profiles, including both your own profile and other members' profiles." If your plan was for a recruiter to bulk-save a pipeline, that is the ceiling, and it counts their own profile too.

The file itself is an ordinary text-layer PDF, which means any parser that reads PDFs can read it. What it is not is structured: the section headings are visual, the dates are free text, and the skills are a flat run of lines. Turning it into fields is the same job as parsing any other CV, and the same tools apply — see open source resume parser for what the self-hosted options return.

Download your data — CSVs, not a resume

LinkedIn's Download your data flow lives under Settings & Privacy → Data Privacy → Download your data. You choose either specific categories or a larger archive, and LinkedIn emails a link.

Two timings decide whether this can sit inside a user-facing flow at all. LinkedIn says that for a specific data type "we'll email you within minutes", and for the larger download "you'll receive an email within 24 hours". The link then stays live for a bounded window: "The data will be available for download for 72 hours."

A 24-hour wait means this cannot be a synchronous step in a signup. If you want it in a product, it is an asynchronous import: the user requests the archive, comes back, and uploads the ZIP.

What is inside is a set of CSV files — Positions.csv, Education.csv, Skills.csv, Profile.csv and so on — one row per item. That is good news and bad news. Good: it is already tabular, so you do not need a parser to find the fields, and a few lines of CSV reading gets you most of the way. Bad: the columns are LinkedIn's, not your schema's, dates are strings in LinkedIn's own formatting, and you still have to normalise and merge the files into one candidate record. Budget for a mapping layer, not a parser.

Member Portability APIs — real, and regional

LinkedIn's data-download page also notes that "LinkedIn provides an API program to enable EU/EEA/Switzerland members to access their LinkedIn data programmatically." This is the cleanest route technically — structured data, no file handling — and it is the one you can build on for the smallest share of the world's candidates. Treat it as an optimisation for European users if you have them, never as the primary path.

What this means for your design

Putting the three together, a LinkedIn import feature usually ends up shaped like this:

• Accept a PDF upload, because it is the only export that works for someone else's profile and the only one a user can produce in under a minute.
• Accept an ordinary CV too, in the same endpoint. A candidate who cannot produce a LinkedIn PDF — wrong language, mobile, over the cap, no LinkedIn account — has a DOCX on their laptop, and you do not want two ingest paths.
• Treat the archive as a separate, asynchronous importer if you serve members exporting their own account, and read it as CSV rather than parsing it.
• Do not plan around scraping profiles. LinkedIn's User Agreement puts it in the "Don'ts", and the wording covers the obvious workarounds:

Develop, support or use software, devices, scripts, robots or any other means or processes (such as crawlers, browser plugins and add-ons or any other technology) to scrape or copy the Services, including profiles and other data from the Services

A pipeline built on that is a product decision away from breaking, quite apart from the agreement.

Because the first two bullets collapse into one — parse a PDF or DOCX into fields — the "LinkedIn resume parser" you need is, in practice, just a resume parser that handles the LinkedIn PDF as one of its layouts.

Getting typed JSON out of the PDF

Two honest options, and which is right depends on whether parsing is your product.

Run a library yourself. No licence cost, no vendor, and the LinkedIn PDF is a relatively tidy input compared to a designer's CV. You own accuracy, upgrades and the long tail of layouts. Our survey of what is actually maintained is in python resume parser and open source resume parser; the short version is that the well-kept tools in this space extract text and layout rather than resume fields, so the field-mapping work is yours either way.

Call a parsing API. You post the file and get fields back. This is what we sell, so here is the specific shape rather than an argument: ResumeJSON takes a PDF, a DOCX, plain text, or a photo or scan of a CV, and returns typed JSON — name and contact details, every role with dates normalised to YYYY-MM, education, skills, certifications and languages. A field the document does not state comes back null rather than guessed, and there is no score, rank or fit judgement in the response, because there is no such field in the schema. Median parse is 2.2 seconds.

What it costs, against the LinkedIn cap

Plans are metered and billed through RapidAPI. Worth setting beside LinkedIn's 200-PDF monthly cap: if the PDFs are being saved by hand, LinkedIn's limit binds long before any parsing plan does. At 200 profiles a month the parsing is $10 on pay-per-use, or free on Basic for the first hundred.

When you should not buy a parser at all

If your input is the data archive rather than the PDF, skip this category entirely. The CSVs are already structured; a parser adds a step and a cost to data that does not need parsing. Write the mapping layer and be done.

If you are an enterprise buying a taxonomy, matching and search alongside extraction, a per-parse API is the wrong shape and a platform vendor is the right one — see resume parsing software for how those three categories differ and which questions separate them.

Try it on a real LinkedIn PDF

The cheapest way to settle whether any of this works for your documents is to save one profile to PDF and run it. Our free parser takes a file and shows the JSON, with no signup, so you can see exactly which fields a LinkedIn export fills and which come back null before you write a line of integration code. Ten of your own files settles more than any table on this page.