# Is it possible to create a Résumé parser using a Huggingface model?

**URL:** <https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840>\
**Category:** Beginners\
**Created:** [December 15, 2020, 10:48pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840 "2020-12-15T22:48:03Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![xjdeng](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/xjdeng/32/771_2.png) [@xjdeng](https://discuss.huggingface.co/u/xjdeng)\
**Post date:** [December 15, 2020, 10:48pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/1 "2020-12-15T22:48:03Z")

</div>

In other words, is it possible to train a supervised transformer model to pull out specific from unstructured or semi-structured text and if so, which pretrained model would be best for this?

In the resume example, I’d want to input the text version of a person’s resume and get a json like the following as output: {‘Education’: [‘BS Harvard University 2010’, ‘MS Stanford University 2012’], ‘Experience’: [‘Microsoft, 2012-2016’, ‘Google, 2016 - Present’]}

Obviously, I’ll need to label hundreds or thousands of resumes with their relevant Education and Experience fields before I’ll have a model that is capable of the above.

Here’s another [example](https://twitter.com/theaievangelist/status/1301202531809361926?lang=en) of the solution that I’m talking about although this person seems to be using GPT-3 and didn’t have any code provided. Is this something that any of the huggingface [pipelines](https://huggingface.co/transformers/main_classes/pipelines.html) is capable of and if so, which pipeline would be most appropriate?

---

<div class="post-metadata">

**Author:** ![FL33TW00D](https://avatars.discourse-cdn.com/v4/letter/f/e0b2c6/32.png) [@FL33TW00D](https://discuss.huggingface.co/u/FL33TW00D)\
**Post date:** [December 15, 2020, 10:54pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/2 "2020-12-15T22:54:40Z")

</div>

Is there any reason you’re looking to do this with a transformer?  
This is a common vision problem, and transformers aren’t usually the first port of call for a problem like this.

---

<div class="post-metadata">

**Author:** ![xjdeng](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/xjdeng/32/771_2.png) [@xjdeng](https://discuss.huggingface.co/u/xjdeng)\
**Post date:** [December 15, 2020, 10:56pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/3 "2020-12-15T22:56:02Z")

</div>

I’m looking to do this with a transformer because I’ll be receiving the raw text, not images, as input.

And yes, I’m using the Resume example as a proxy for a confidential use case at my company.

---

<div class="post-metadata">

**Author:** ![clem](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/clem/32/2838_2.png) [@clem](https://discuss.huggingface.co/u/clem)\
**Post date:** [December 16, 2020, 1:00am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/4 "2020-12-16T01:00:18Z")

</div>

Yes, we’ve seen companies using transformers for similar use cases. If you don’t have a lot of labelled data, it usually involves a mix of zero-shot classification to understand the sections (ex: [https://huggingface.co/facebook/bart-large-mnli?text=2001+-+2003+harvard%2C+master+in+management&labels=school%2C+job%2C+hobbies&multiclass=false](https://huggingface.co/facebook/bart-large-mnli?text=2001+-+2003+harvard%2C+master+in+management&labels=school%2C+job%2C+hobbies&multiclass=false)) and then NER to extract the right information for the right classes ([https://huggingface.co/dslim/bert-base-NER?text=I+worked+at+Facebook](https://huggingface.co/dslim/bert-base-NER?text=I+worked+at+Facebook)). Sometimes you want to add entity linking to the mix depending on how elaborate a system you need.

Would you be open to jump on a call to see if some of our commercial offering could be useful or are you looking at doing that all by yourself?

---

<div class="post-metadata">

**Author:** ![facehugger2020](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/facehugger2020/32/3052_2.png) [@facehugger2020](https://discuss.huggingface.co/u/facehugger2020)\
**Post date:** [December 16, 2020, 1:02am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/5 "2020-12-16T01:02:41Z")

</div>

This is a common NLP problem, and transformers are a good first port of call for a problem like this.

You should google these terms:

- Named entity recognition
- Chunking

You’ll need to have labeled data, usually marking every token in your document with perhaps [IOB tags](https://en.wikipedia.org/wiki/Inside%E2%80%93outside%E2%80%93beginning_(tagging)) that can demarcate the start and end of a coherent chunk of text.

---

<div class="post-metadata">

**Author:** ![xjdeng](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/xjdeng/32/771_2.png) [@xjdeng](https://discuss.huggingface.co/u/xjdeng)\
**Post date:** [December 16, 2020, 2:48am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/6 "2020-12-16T02:48:15Z")

</div>

The problem I’m trying to solve, in the most general sense, is that you’re given a set of documents and each document in your set has specific information that you’re trying to pull out. Examples of specific information to pull out include:

- Author of the document
- When was the document written
- Who is the recipient of the document
- etc.

And keep in mind information in the document may not always be stated in an obvious way. In one document, the author may be given as “Author: Joe Shmo”. In another one it might say: “From Jane Doe”. But let’s assume that every document has an author and any normal adult human with an average comprehension of English can pull out the author even though the author may not be stated in the exact same way in each document (and let’s assume there are countless ways of saying who the author is and no reasonable Regex pattern can be used to pull it out.) Ditto to the other fields like the date when it’s written and the intended recipient of the document.

I originally thought of using a Question Answering model as a basis for this task but it might be overkill. Regarding the Resume example, I might end up training the model on just two questions and their respective answers for each resume in the dataset:

- What is the education?
- What is the experience?

I suppose training a custom NER model might be another route to take.

---

<div class="post-metadata">

**Author:** ![facehugger2020](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/facehugger2020/32/3052_2.png) [@facehugger2020](https://discuss.huggingface.co/u/facehugger2020)\
**Post date:** [December 16, 2020, 10:18pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/7 "2020-12-16T22:18:56Z")

</div>

> Is there any reason you’re looking to do this with a transformer?  
> This is a common vision problem, and transformers aren’t usually the first port of call for a problem like this.

LOL. What?

---

<div class="post-metadata">

**Author:** ![FL33TW00D](https://avatars.discourse-cdn.com/v4/letter/f/e0b2c6/32.png) [@FL33TW00D](https://discuss.huggingface.co/u/FL33TW00D)\
**Post date:** [December 16, 2020, 11:28pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/8 "2020-12-16T23:28:30Z")

</div>

I misread I thought he had the physical resumes and was jumping straight to: [https://arxiv.org/abs/2010.11929](https://arxiv.org/abs/2010.11929)

---

<div class="post-metadata">

**Author:** ![meditations](https://avatars.discourse-cdn.com/v4/letter/m/9f8e36/32.png) [@meditations](https://discuss.huggingface.co/u/meditations)\
**Post date:** [July 15, 2021, 1:18am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/9 "2021-07-15T01:18:10Z")

</div>

Hi @clem would be very interested in checking out HF’s commercial offering for this. Can we chat somehow?

---

<div class="post-metadata">

**Author:** ![tnavin](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@tnavin](https://discuss.huggingface.co/u/tnavin)\
**Post date:** [August 3, 2022, 12:05am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/10 "2022-08-03T00:05:17Z")

</div>

Hey clem. Can we jump on a call to look into your offerings regarding the same? Thanks.

---

<div class="post-metadata">

**Author:** ![nielsr](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/nielsr/32/39617_2.png) [@nielsr](https://discuss.huggingface.co/u/nielsr)\
**Post date:** [August 3, 2022, 9:44am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/11 "2022-08-03T09:44:37Z")

</div>

Hi,

We do have several models available for that. These include (at the time of writing):

- [LayoutLM](https://huggingface.co/docs/transformers/model_doc/layoutlm)
- [LayoutLMv2](https://huggingface.co/docs/transformers/model_doc/layoutlmv2)
- [LayoutLMv3](https://huggingface.co/docs/transformers/model_doc/layoutlmv3)
- [Document Image Transformer](https://huggingface.co/docs/transformers/model_doc/dit)
- [TrOCR](https://huggingface.co/docs/transformers/model_doc/trocr)

LayoutLM is a BERT-like model by Microsoft that adds layout information of the text tokens to improve performance on document processing tasks, like information extraction from documents, document image classification and document visual question answering. Its successors are LayoutLMv2 and v3 which improve its performance. Notebooks for all of those can be found in my [Github repo](https://github.com/NielsRogge/Transformers-Tutorials).

Then there are also the Document Image Transformer, which is mostly suited for document image classification and layout analysis (like table detection in PDFs), and TrOCR, which is a Transformer-based encoder-decoder model for optical character recognition on single text-line images. Notebooks for those can also be found in my Github repo.

---

<div class="post-metadata">

**Author:** ![Sybghat](https://avatars.discourse-cdn.com/v4/letter/s/d9b06d/32.png) [@Sybghat](https://discuss.huggingface.co/u/Sybghat)\
**Post date:** [April 14, 2023, 9:28am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/13 "2023-04-14T09:28:28Z")

</div>

Yes it is possible and infect i have a demo available on my space [here](https://huggingface.co/spaces/Sybghat/resume-parser). It was initial version and i uploaded that almost an year ago.

---

<div class="post-metadata">

**Author:** ![rakin061](https://avatars.discourse-cdn.com/v4/letter/r/ac8455/32.png) [@rakin061](https://discuss.huggingface.co/u/rakin061)\
**Post date:** [October 12, 2023, 5:32am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/14 "2023-10-12T05:32:10Z")

</div>

@Sybghat Can you share your source code if uploaded in github or so ??

---

<div class="post-metadata">

**Author:** ![radames](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/radames/32/28246_2.png) [@radames](https://discuss.huggingface.co/u/radames)\
**Post date:** [October 12, 2023, 8:12pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/15 "2023-10-12T20:12:46Z")

</div>

you can see the source here [Sybghat/resume-parser at main](https://huggingface.co/spaces/Sybghat/resume-parser/tree/main)

---

<div class="post-metadata">

**Author:** ![umesh19](https://avatars.discourse-cdn.com/v4/letter/u/45deac/32.png) [@umesh19](https://discuss.huggingface.co/u/umesh19)\
**Post date:** [October 18, 2023, 5:55am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/16 "2023-10-18T05:55:41Z")

</div>

1. i have found this [deepset/tinyroberta-squad2](https://huggingface.co/deepset/tinyroberta-squad2) but this will work only when resume contains label i have used this using haystack

2. [impira/layoutlm-document-qa](https://huggingface.co/impira/layoutlm-document-qa) which use LayoutLM behind which work fine but its again i have passed resume without name label only values it cannot detected

---

<div class="post-metadata">

**Author:** ![ddeisadze](https://avatars.discourse-cdn.com/v4/letter/d/4af34b/32.png) [@ddeisadze](https://discuss.huggingface.co/u/ddeisadze)\
**Post date:** [March 22, 2024, 12:36am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/17 "2024-03-22T00:36:25Z")

</div>

How accurate is your model?

---

<div class="post-metadata">

**Author:** ![ddeisadze](https://avatars.discourse-cdn.com/v4/letter/d/4af34b/32.png) [@ddeisadze](https://discuss.huggingface.co/u/ddeisadze)\
**Post date:** [March 22, 2024, 12:36am UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/18 "2024-03-22T00:36:55Z")

</div>

@xjdeng where you able to find something accurate to extract that info?

---

<div class="post-metadata">

**Author:** ![jiroxin](https://avatars.discourse-cdn.com/v4/letter/j/ad7895/32.png) [@jiroxin](https://discuss.huggingface.co/u/jiroxin)\
**Post date:** [May 31, 2026, 4:09pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/19 "2026-05-31T16:09:30Z")

</div>

Hey,

It’s crazy that the thread started in 2020, got a reasonable answer after 2 years by @nielsr, and it’s still ongoing in 2026.  
I’m too working on a similar project as @xjdeng using [LayoutLMv3](https://huggingface.co/docs/transformers/model_doc/layoutlmv3), but i’m currently stuck at the training phase because i haven’t been able to find a decent resume dataset to train on.

if anyone can provide some guidance or point toward a suitable resources, i would be very grateful.

Thanks

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [June 3, 2026, 9:04pm UTC](https://discuss.huggingface.co/t/is-it-possible-to-create-a-resume-parser-using-a-huggingface-model/2840/20 "2026-06-03T21:04:59Z")

</div>

For now, version as of June 2026… This probably changes quite a bit depending on whether you specifically need to make it work with LayoutLMv3, or whether any model/tool is acceptable as long as the resume parsing goal is met:

* * *

## TL;DR

I would split this into two different tracks:

1. **If you specifically need LayoutLMv3** , the main problem is not just “which model?” or “which dataset?”. You need a dataset/pipeline with:

2. **If the goal is simply resume parsing / resume information extraction** , then there are more practical resources now. I would look at:

The most important practical distinction is:

> LayoutLMv3 wants image + OCR words + boxes + labels.  
> Many newer resume resources are text-to-JSON, NER, OCR, or document-parsing resources. Useful, but not the same training format.

* * *

## Track A — If you must use LayoutLMv3

For LayoutLMv3, I would first check the expected input contract carefully.

Relevant docs:

- [LayoutLMv3 docs](https://huggingface.co/docs/transformers/en/model_doc/layoutlmv3)
- [LayoutLMv3 model card: microsoft/layoutlmv3-base](https://huggingface.co/microsoft/layoutlmv3-base)
- [HF forum: LayoutLMv3 for token classification](https://discuss.huggingface.co/t/layoutlmv3-for-token-classification/21331)

The important part is that LayoutLMv3 token classification is not just ordinary text NER. The processor/model path expects layout-aware inputs, usually something like:

```python
{
    "image": "<page image>",
    "words": ["John", "Doe", "Software", "Engineer", "..."],
    "boxes": [[x0, y0, x1, y1], ...],
    "word_labels": ["B-NAME", "I-NAME", "B-TITLE", "I-TITLE", "..."]
}

```

The boxes should be word-level bounding boxes, normalized in the LayoutLM-style coordinate system, usually 0–1000 scale. The labels need to align with the OCR words, and then the tokenizer has to propagate word labels to subword tokens.

The forum thread above is worth reading because it points out a common failure mode: training with one kind of box/annotation setup, then using a different OCR/bbox setup at inference. That can break the model even if the training code looked fine.

### Practical LayoutLMv3 checklist

If I had to make the LayoutLMv3 route work, I would do something like this:

```plaintext
1. Choose one OCR engine and freeze it.
   Examples: Tesseract, EasyOCR, PaddleOCR, pdfplumber/PDF text extraction, etc.

2. Convert each resume page into:
   - page image
   - OCR words
   - word-level bounding boxes
   - reading order

3. Annotate those OCR words/boxes.
   Do not annotate totally separate hand-drawn boxes unless you can reproduce the same boxes at inference.

4. Convert annotations into BIO/BILOU labels.
   Example labels:
   - B-NAME / I-NAME
   - B-EMAIL / I-EMAIL
   - B-PHONE / I-PHONE
   - B-COMPANY / I-COMPANY
   - B-JOB_TITLE / I-JOB_TITLE
   - B-DEGREE / I-DEGREE
   - B-INSTITUTION / I-INSTITUTION
   - B-SKILL / I-SKILL
   - O

5. Normalize boxes exactly as LayoutLMv3 expects.

6. Keep OCR, ordering, box normalization, truncation, and page splitting identical at training and inference.

7. Start with a small gold evaluation set before scaling.

```

In other words, for LayoutLMv3 the dataset problem is really an **annotation and preprocessing contract** problem.

### Why ordinary resume text datasets are not enough for LayoutLMv3

A dataset like:

```json
{
  "text": "John Doe\nSoftware Engineer\n...",
  "json": {
    "name": "John Doe",
    "title": "Software Engineer"
  }
}

```

can be useful for text-to-JSON models or LLM fine-tuning, but it is not directly enough for LayoutLMv3 token classification because it is missing:

- page image,
- OCR words,
- word bounding boxes,
- word-level labels,
- reading order,
- box normalization,
- page-level segmentation.

You might still use a text-to-JSON model to create **weak labels**. For example:

```plaintext
resume PDF
→ OCR words + boxes
→ text-to-JSON extractor
→ extracted field values
→ string-match field values back to OCR words
→ weak BIO labels
→ human correction
→ LayoutLMv3 fine-tuning

```

But I would treat that as a weak-labeling/bootstrap approach, not as a clean substitute for a real gold dataset.

### A LayoutLMv3-adjacent resource

One interesting LayoutLMv3-related resume resource is:

- [Smutypi3/applai-layoutlmv3](https://huggingface.co/Smutypi3/applai-layoutlmv3)

I would not treat it as a complete resume field parser, but it is relevant because it uses LayoutLMv3 on resume PDFs and discusses a resume-oriented preprocessing pattern. It may be useful as a reference if you want to see how someone handled PDF words, boxes, and LayoutLMv3-style representations in the resume domain.

* * *

## Track B — If any model/tool is acceptable

If the goal is simply “parse resumes into structured fields”, I would probably not start with LayoutLMv3. I would start with a pipeline view:

```plaintext
PDF / DOCX / image resume
→ OCR / PDF parsing / layout reconstruction
→ clean text or Markdown with reading order
→ section routing
→ structured extraction
→ JSON validation
→ evaluation on a small hand-checked set

```

A resume parser is often not one model. It is a pipeline.

The hard part may be upstream: converting a visually complex resume PDF into faithful text/Markdown/layout before extracting fields.

* * *

## Strongest current resource: SmartResume

I would look at SmartResume first:

- [GitHub: alibaba/SmartResume](https://github.com/alibaba/SmartResume)
- [HF model repo: Alibaba-EI/SmartResume](https://huggingface.co/Alibaba-EI/SmartResume)
- [Paper: Layout-Aware Parsing Meets Efficient LLMs](https://arxiv.org/abs/2510.09722)
- [HF Papers page](https://huggingface.co/papers/2510.09722)

Why it matters:

SmartResume is very close to the actual problem. It is not just a generic NER model. It treats resume parsing as a layout-aware pipeline:

```plaintext
resume PDF / image / Office document
→ OCR + PDF metadata extraction
→ layout detection
→ reading order reconstruction
→ structured information extraction with a compact LLM

```

The paper is especially useful because it frames the problem correctly:

- resumes have diverse layouts,
- resumes often have multi-column structures,
- reading order matters,
- LLM-only extraction can be expensive or brittle,
- standardized resume extraction datasets/evaluation tools are limited.

This is probably the best “goal-first” starting point I found.

* * *

## General structured extraction: NuExtract3

Another strong candidate is:

- [numind/NuExtract3](https://huggingface.co/numind/NuExtract3)

This is not resume-specific, but it is very relevant. It is a vision-language document understanding model for structured extraction and image-to-Markdown conversion.

The useful pattern is:

```plaintext
input document + JSON template + optional instructions
→ structured JSON output

```

For a resume, the template might look like:

```json
{
  "name": "verbatim-string",
  "email": "email",
  "phone": "verbatim-string",
  "location": "verbatim-string",
  "summary": "string",
  "skills": ["verbatim-string"],
  "education": [
    {
      "institution": "verbatim-string",
      "degree": "verbatim-string",
      "field": "verbatim-string",
      "start_date": "date-time",
      "end_date": "date-time"
    }
  ],
  "experience": [
    {
      "company": "verbatim-string",
      "title": "verbatim-string",
      "location": "verbatim-string",
      "start_date": "date-time",
      "end_date": "date-time",
      "responsibilities": ["string"],
      "achievements": ["string"]
    }
  ],
  "certifications": [
    {
      "name": "verbatim-string",
      "issuer": "verbatim-string",
      "date": "date-time"
    }
  ]
}

```

I would still evaluate it on real resumes. But as a modern structured-extraction route, it is very relevant.

* * *

## OCR / document parsing layer: PaddleOCR-VL, PaddleOCR 3.5, Docling, olmOCR

If your input is PDF/image resumes, I would also look at current OCR/document parsing tools. These are not resume parsers by themselves, but they may solve the most painful upstream step.

Useful resources:

- [PaddleOCR-VL](https://huggingface.co/PaddlePaddle/PaddleOCR-VL)
- [PaddleOCR-VL-1.6 collection](https://huggingface.co/collections/PaddlePaddle/paddleocr-vl-16)
- [PaddleOCR GitHub](https://github.com/PaddlePaddle/PaddleOCR)
- [HF Blog: PaddleOCR 3.5 with Transformers backend](https://huggingface.co/blog/PaddlePaddle/paddleocr-transformers)
- [Docling GitHub](https://github.com/docling-project/docling)
- [Docling docs](https://docling-project.github.io/docling/)
- [Docling technical report](https://arxiv.org/abs/2408.09869)
- [olmOCR GitHub](https://github.com/allenai/olmocr)
- [olmOCR paper](https://arxiv.org/abs/2502.18443)

Why this matters:

A two-column resume, a sidebar resume, or a scanned resume can fail before the extraction model even sees the content correctly. If the OCR/layout step scrambles the reading order, a good NER or LLM extractor may still produce bad JSON.

So I would separate:

```plaintext
document parsing quality

```

from:

```plaintext
field extraction quality

```

They are related, but not the same problem.

* * *

## Resume text → JSON resources

If you can already get reasonably clean text from the resume, there are more direct resources.

### Qwen3 resume JSON dataset/model

- [sandeeppanem/resume-json-extraction-5k](https://huggingface.co/datasets/sandeeppanem/resume-json-extraction-5k)
- [sandeeppanem/qwen3-0.6b-resume-json](https://huggingface.co/sandeeppanem/qwen3-0.6b-resume-json)
- [GitHub: sandeeppanem/qwen3-resume-extraction](https://github.com/sandeeppanem/qwen3-resume-extraction)

This route is useful if your pipeline is:

```plaintext
PDF/DOCX/image
→ text extraction
→ raw resume text
→ structured JSON extractor

```

The dataset is raw resume text to structured JSON. The model is a Qwen3-0.6B LoRA adapter for resume JSON extraction.

Caveats:

- It is not a LayoutLMv3 dataset.
- It does not solve OCR/layout.
- The model repo contains the LoRA adapter, so the base model is also needed.
- Long resumes and unusual formats still need evaluation.

### Small local resume extractor

- [nimendraai/NuExtract-tiny-Resume-Data-Extractor](https://huggingface.co/nimendraai/NuExtract-tiny-Resume-Data-Extractor)

This is a resume/CV structured extraction model based on NuExtract-tiny / Qwen2.5-0.5B. It is useful if you want a small local route, especially for raw text to JSON.

Caveat: check the model card carefully. It is trained on synthetic resumes, so I would not trust it without testing on real resumes from your target distribution.

* * *

## NER / section-routing route

If you want something more deterministic and easier to debug than “LLM returns JSON”, a section classifier + NER pipeline may be easier to control.

Useful resources:

- [oksomu/resume-ner](https://huggingface.co/oksomu/resume-ner)
- [amosify/resume-section-classifier-v1](https://huggingface.co/amosify/resume-section-classifier-v1)
- [amosify/distilbert-resume-ner-v1](https://huggingface.co/amosify/distilbert-resume-ner-v1)
- [yashpwr/resume-ner-training-data](https://huggingface.co/datasets/yashpwr/resume-ner-training-data)
- [yashpwr/resume-ner-bert-v2](https://huggingface.co/yashpwr/resume-ner-bert-v2)
- [HF docs: token classification / NER](https://huggingface.co/docs/transformers/en/tasks/token_classification)

A practical version of this route could be:

```plaintext
OCR/PDF text chunks
→ classify chunks into sections:
   contact / summary / experience / education / skills / certifications / projects / etc.
→ run section-aware NER
→ normalize dates, phone, email, skills, company names
→ group entities into experience[] and education[]
→ validate JSON

```

This is less glamorous than a single end-to-end model, but easier to debug.

For example:

- Contact fields can often be handled with regex + NER.
- Skills can use NER + skill dictionaries.
- Experience needs grouping: company, title, dates, bullet points.
- Education needs grouping: institution, degree, field, dates/GPA.

The important caveat with many resume NER models is that reported scores may come from internal or narrow test sets. I would always create a small hand-labeled evaluation set from your actual target resumes.

* * *

## Resource table

| Resource | Type | Best for | Not for | Notes |
| --- | --- | --- | --- | --- |
| [LayoutLMv3 docs](https://huggingface.co/docs/transformers/en/model_doc/layoutlmv3) | Model docs | Understanding LayoutLMv3 input contract | Finding resume data | Essential for image/words/boxes/labels |
| [LayoutLMv3 forum thread](https://discuss.huggingface.co/t/layoutlmv3-for-token-classification/21331) | Forum/debugging | OCR/bbox train-inference consistency | Turnkey solution | Very relevant practical warning |
| [SmartResume](https://github.com/alibaba/SmartResume) | Resume-specific system | Full resume parsing pipeline | Pure LayoutLMv3 training | Strongest goal-first candidate |
| [Alibaba-EI/SmartResume](https://huggingface.co/Alibaba-EI/SmartResume) | Model repo | Weights/resources for SmartResume | General NER | Includes resume extraction/layout components |
| [Layout-Aware Parsing Meets Efficient LLMs](https://arxiv.org/abs/2510.09722) | Paper | Modern resume extraction architecture | Drop-in code alone | Useful framing and evaluation discussion |
| [NuExtract3](https://huggingface.co/numind/NuExtract3) | General document extraction VLM | Template-based JSON extraction | Resume-specific guarantee | Strong candidate if model choice is flexible |
| [PaddleOCR-VL](https://huggingface.co/PaddlePaddle/PaddleOCR-VL) | OCR/document parsing | Upstream PDF/image parsing | Resume field extraction by itself | Strong document parsing candidate |
| [PaddleOCR GitHub](https://github.com/PaddlePaddle/PaddleOCR) | OCR/document stack | OCR/layout/table/formula/chart extraction | Resume-specific schema | Good ingestion layer |
| [Docling](https://github.com/docling-project/docling) | Document parser | PDF/DOCX/image to structured text/Markdown/JSON | Resume labels | Useful preprocessing layer |
| [olmOCR](https://github.com/allenai/olmocr) | PDF-to-text/Markdown OCR | Clean reading order / linearized text | Resume JSON fields | Useful before extraction |
| [resume-json-extraction-5k](https://huggingface.co/datasets/sandeeppanem/resume-json-extraction-5k) | Dataset | Resume text → JSON SFT | LayoutLMv3 training | Directly relevant for text route |
| [qwen3-0.6b-resume-json](https://huggingface.co/sandeeppanem/qwen3-0.6b-resume-json) | LoRA adapter | Lightweight resume JSON extraction | OCR/layout | Needs base Qwen3 model |
| [NuExtract-tiny Resume](https://huggingface.co/nimendraai/NuExtract-tiny-Resume-Data-Extractor) | Small local extractor | Local raw-text resume JSON extraction | Robust PDF layout | Synthetic-data caveat |
| [oksomu/resume-ner](https://huggingface.co/oksomu/resume-ner) | NER + postprocess | Deterministic entity extraction route | Full layout parsing | Detailed card; evaluate externally |
| [amosify section classifier](https://huggingface.co/amosify/resume-section-classifier-v1) | Text classifier | Section routing | Field extraction alone | Useful middle layer |
| [amosify resume NER](https://huggingface.co/amosify/distilbert-resume-ner-v1) | NER model | Section-aware NER | Nested JSON alone | Pair with section routing |
| [resume-parsing model tag](https://huggingface.co/models?other=resume-parsing) | HF model search | Discovering current resume models | Exhaustive coverage | Some models are not tagged consistently |

* * *

## Suggested practical pipelines

### Pipeline 1: LayoutLMv3-only route

Use this if LayoutLMv3 is required.

```plaintext
resume PDF/image
→ render pages
→ OCR with one fixed engine
→ words + word boxes + reading order
→ annotate OCR words/boxes
→ BIO labels
→ LayoutLMv3 token classification
→ field grouping + post-processing
→ JSON validation

```

This is the most faithful LayoutLMv3 route, but also the most annotation-heavy.

### Pipeline 2: Modern model-free route

Use this if the goal is just accurate resume parsing.

```plaintext
resume PDF/DOCX/image
→ Docling / PaddleOCR / olmOCR / SmartResume-style parsing
→ Markdown or layout-preserving text
→ NuExtract3 / SmartResume / Qwen3-resume-json / NER pipeline
→ structured JSON
→ validation and evaluation

```

This is probably the more practical route for most projects.

### Pipeline 3: Hybrid route

Use this if you want to eventually train LayoutLMv3, but need a bootstrap path.

```plaintext
resume PDF/image
→ OCR words + boxes
→ text-to-JSON or NER extractor
→ map extracted field values back to OCR words
→ create weak BIO labels
→ manually correct a subset
→ train LayoutLMv3
→ evaluate against gold set

```

This can reduce annotation cost, but weak labels can be noisy.

* * *

## Evaluation checklist

For resume parsing, I would not evaluate only “does it produce JSON?”. I would check:

| Aspect | Example |
| --- | --- |
| JSON validity | Does it always return parseable JSON? |
| Schema compliance | Does it follow the target schema exactly? |
| Field exact match | email, phone, URLs |
| Normalized match | dates, locations, company names |
| Semantic match | job titles, degree names, responsibilities |
| Array alignment | does each title match the correct company/date range? |
| Omission | did it miss an experience item or degree? |
| Hallucination | did it invent a company, skill, date, or degree? |
| Layout robustness | two-column resumes, sidebars, scanned PDFs |
| Long-document handling | multi-page resumes, truncation, repeated headers |
| Privacy handling | PII, consent, local processing, data retention |

For structured extraction evaluation ideas, you can also look at:

- [ExtractBench](https://arxiv.org/abs/2602.12247)
- [ParseBench dataset](https://huggingface.co/datasets/llamaindex/ParseBench)
- [OmniDocBench](https://github.com/opendatalab/OmniDocBench)

These are not resume-specific, but they are useful for thinking about PDF-to-JSON and document parsing evaluation.

* * *

## How I would keep searching

I would not rely only on the `resume-parsing` tag. Some newer models are weakly tagged or not tagged consistently.

Search across:

### Hugging Face Models

- [resume parser](https://huggingface.co/models?search=resume%20parser)
- [resume json](https://huggingface.co/models?search=resume%20json)
- [cv parser](https://huggingface.co/models?search=cv%20parser)
- [resume ner](https://huggingface.co/models?search=resume%20ner)
- [qwen resume parser](https://huggingface.co/models?search=qwen%20resume%20parser)
- [deepseek resume parser](https://huggingface.co/models?search=deepseek%20resume%20parser)
- [resume-parsing tag](https://huggingface.co/models?other=resume-parsing)

### Hugging Face Spaces

Search for resume parser demos, but inspect the implementation:

- `app.py`
- `requirements.txt`
- model calls
- OCR/PDF parsing method
- whether it handles PDF, DOCX, image, or only raw text
- whether there is any evaluation

Spaces are useful for implementation patterns, but I would not treat a demo as evidence of model quality.

### Blogs / Papers / Posts

Also watch document parsing and OCR releases, not just resume-specific models.

Useful entry points:

- [Hugging Face Papers](https://huggingface.co/papers)
- [Hugging Face Blog](https://huggingface.co/blog)
- [Hugging Face Posts](https://huggingface.co/posts)
- [PaddleOCR 3.5 HF blog](https://huggingface.co/blog/PaddlePaddle/paddleocr-transformers)
- [OCR open models blog](https://huggingface.co/blog/ocr-open-models)

The reason is that the hardest part may be converting the resume PDF/image into a faithful text/layout representation before the actual field extraction step.

* * *

## My practical recommendation

If I were trying to solve this now, I would do this:

1. **If LayoutLMv3 is mandatory:**

2. **If any model/tool is acceptable:**

3. **In both cases:**

So my short answer would be:

> I did not find a perfect public LayoutLMv3-ready resume dataset.  
> But if the goal is resume parsing rather than specifically LayoutLMv3 training, the ecosystem is much better now: SmartResume, NuExtract3, PaddleOCR-VL/PaddleOCR, Qwen3 resume JSON, NuExtract-tiny Resume, and resume NER/section-routing models are all worth checking.