When you paste your resume into an online application, an automated text extractor usually processes it first. What looks clean and legible on your screen can look completely disordered behind the scenes. If you have ever previewed an application profile and found your work history cut off, your skill list fused into a single unreadable word, or an entire section missing, you are dealing with a formatting breakdown.
Understanding resume tables, text boxes, and graphics extraction requires looking past the visual layout and examining the digital text stream. Software parsers do not "see" visual borders, columns, or colored panels the way humans do. Instead, they interpret an underlying stream of coordinates, characters, and data objects. To demonstrate exactly where and how extraction fails, we conducted controlled tests comparing identical text rendered through plain layouts, bordered tables, text boxes, and embedded graphics.
Controlled Benchmark: One Resume, Four Formats
To observe extraction behavior directly, we ran a controlled test through Career Copilot's production parser (POST /v1/tools/parse-check) on November 1, 2026. The test used a synthetic, fictional candidate profile: Alex Carter — Backend Engineer (with fictional details using example.com domains and a 555 contact number).
Every word in the body was kept identical across four PDF variants, except for how two specific probe phrases were rendered:
- P1 (Skills line):
Python, PostgreSQL, Redis, Apache Kafka, Docker, AWS, REST API design - P2 (Achievement bullet):
- Led migration of the checkout API to an event-driven design
The four variants tested were:
v_plain.pdf: Standard plain-text layout (baseline).v_table.pdf: P1 placed in a multi-cell table row (each skill in its own bordered cell); P2 in a single full-width cell; job titles, companies, and dates split across bordered multi-column cells.v_textbox.pdf: P1 and P2 each enclosed in a drawn rectangular text box containing a standard digital text layer.v_graphic.pdf: P1 and P2 rendered solely as embedded PNG images, leaving zero underlying digital text for those two phrases.
A local text analysis using pypdf confirmed that v_plain (939 characters), v_table (929 characters), and v_textbox (939 characters) all contained the digital text of both probes. The graphic variant (v_graphic) contained only 807 characters, verifying beforehand that the probe text was absent from the text stream.
Observed Extraction Results
| Test Variant | Returned Segments | Segment Status | Dropped Segment List | Skills Line (P1) Extraction | Bullet (P2) Extraction |
| :--- | :--- | :--- | :--- | :--- | :--- |
| v_plain | 19 | 19 intact | [] (empty) | Verbatim with commas intact | Verbatim |
| v_table | 19 | 19 intact | [] (empty) | Extracted, but cell boundaries vanished | Verbatim |
| v_textbox | 19 | 19 intact | [] (empty) | Verbatim with commas intact | Verbatim |
| v_graphic | 17 | 17 intact | [] (empty) | Absent entirely | Absent entirely |
Across all four files, plain contact details (email, phone, location, LinkedIn, GitHub) were extracted cleanly because they sat outside the tested elements. However, the three layout treatments produced distinct extraction behaviors.
1. Tables: Words Survive, but Cell Separators Disappear
In the table test (v_table.pdf), every word was captured, but the structural boundaries vanished. When multi-column table cells were flattened into a sequential text stream, the parser omitted spacing between adjacent cells.
Here is how the skills segment returned from v_plain:
Python, PostgreSQL, Redis, Apache Kafka, Docker, AWS, REST API design
Here is how that exact same line returned from v_table:
PythonPostgreSQLRedisApache KafkaDockerAWSREST API design
Because the individual skills were placed in adjacent cells without explicit punctuation inside the cells, the extractor concatenated them. "PythonPostgreSQL" and "DockerAWSREST" became single merged tokens.
The same merging occurred in the experience section:
Senior Backend EngineerNorthwind Labs2022 - PresentBackend EngineerHelios Commerce2019 - 2022
By contrast, the single full-width row holding the P2 bullet extracted verbatim. This confirms that the problem is not tables inherently, but how parsers handle boundaries across multi-column rows. The words are technically present in the database, but any retrieval query or automated filter looking for individual skill keywords like "Python" or "Docker" may encounter composite strings instead of discrete terms.
2. Text Boxes: Visual Styling vs. Vendor Parsing Rules
In our parser run, v_textbox.pdf returned 19 intact segments identical byte-for-byte to v_plain.pdf. On this specific tool, drawing a visual border around a text block created no extraction penalty because the text layer inside the box was preserved in standard reading order. The border was treated merely as graphical decoration.
However, how text boxes are handled varies across parsing software. For example, applicant tracking system vendor Greenhouse documents several formatting issues as potential causes of a partial parse that requires manual candidate correction. Greenhouse specifically cautions against:
- Placing name and contact information in a header, footer, or text box
- Complex tables, headers, and footers
- Graphics, photos, or word art
- Columned layouts
- Letters spaced apart within words
While our test parser extracted text boxes without error, Greenhouse notes that its parser may misread or disconnect content inside text boxes. If your contact details or experience entries are placed in floating text frames, some parsing engines will extract them out of order or detach them from surrounding sections.
3. Graphics: Silent Loss with No Warning
The most critical failure occurred with embedded images. In v_graphic.pdf, the skills row and the key achievement bullet were converted into flat PNG images inside the PDF.
The parser returned 17 segments instead of 19. Both probe phrases were omitted completely. The skills segment disappeared entirely, causing the SKILLS header segment to be followed immediately by the EDUCATION header segment.
Crucially, the parser gave no indication that anything was missing:
- The API returned a standard
HTTP 200 OK. - All 17 returned segments were marked intact.
- The
dropped_segmentsarray was completely empty ([]).
Because this parser reads the digital text layer rather than running OCR on embedded images, graphic text disappears invisibly from its output. This mirrors an earlier site-measured test on October 23, 2026: when Alex Carter's resume was submitted with a digital text layer, the parser returned 20 intact segments and mapped all contact fields. When submitted as an image-only PDF, it returned zero segments.
Diagnosing Resume Tables, Text Boxes, and Graphics Extraction
If your resume relies on formatting elements for visual polish, use these troubleshooting steps to ensure your content parses reliably:
- Perform the Highlight Test: Open your resume PDF in a standard reader (such as Adobe Acrobat or a browser). Click and drag your cursor over your text. If you cannot highlight words in a table, skill badge, or header, those words are stored as an image and will not be extracted by a standard text parser.
- Perform the Copy-Paste Test: Select the entire page (
Ctrl+AorCmd+A), copy it, and paste it into a plain text editor like Notepad. Check multi-column sections. Did your job title, employer, and dates run together without spaces (e.g.,EngineerNorthwind Labs)? If so, an extraction tool will likely merge those tokens. - Re-Export Directly from the Source Document: If your PDF lacks a text layer, return to your original document in Microsoft Word, Google Docs, or Apple Pages, and choose Save as PDF or Export to PDF. Avoid using "Print to PDF" from image viewers, as this can flatten live text into an unreadable graphic.
- Replace Multi-Cell Tables with Standard Delimiters: Instead of placing each skill into separate grid cells or colored boxes, format them as a continuous text line separated by commas, bullets, or vertical bars:
- *Avoid:* Table grid with one skill per cell.
- *Use:*
Python | PostgreSQL | Redis | Apache Kafka | Docker | AWS
- Linearize Floating Text Containers: Move contact details, summaries, and experience bullets out of floating sidebars, headers, and canvas shapes into the primary document body.
Understanding how data extractors process underlying text allows you to retain clean visual organization without sacrificing machine readability.
To inspect how an automated extractor reads your document's text layer, try the Free Resume Parse Check. It is completely free and requires no account. The tool displays the exact text segments and contact fields detected by this site's parser so you can verify that your content remains intact before submitting applications. Note that this test reflects our parser's extraction rules and does not predict specific outcomes on any employer's internal hiring system.