Accents, Bullets, and Special Characters: A Unicode Survival Test

Technical resumes rarely stick to basic English text. A modern engineering resume might list language proficiencies in Español or Français, reference an office in Zürich, style bullet points with neat geometric glyphs, and feature essential technologies like C++, C#, .NET, and Node.js. Yet job seekers are frequently warned that non-standard symbols will break applicant tracking systems (ATS) or turn their resumes into unreadable gibberish. If you are troubleshooting how resume accents, bullets, special characters, and Unicode elements behave during automated extraction, the reality is far more nuanced than common forum rumors suggest.

Parsing outcomes depend heavily on the underlying structure of your file. When characters are properly encoded within a genuine text layer, modern parsers can handle far more typographical variety than most candidates assume.

#The Non-Negotiable Precondition: A True Text Layer

Before evaluating whether an accent mark or an en dash survives extraction, you must verify that your document contains selectable text. In automated document processing, a character only exists if it is stored in a machine-readable text stream.

In prior measured tests on the Career Copilot parser, submitting a text-layer PDF returned all text segments intact alongside structured contact details. Submitting that exact same resume as a flattened, image-only PDF returned zero text segments. When a document consists entirely of scanned page images or flattened artwork, a parser that reads only the text layer, without OCR, cannot extract any text from it—regardless of whether the visual image shows plain letters or intricate symbols.

If you suspect your resume was rendered as an image:

• The reliable fix: Reopen the original file in your word processor (such as Microsoft Word, Google Docs, or Apple Pages) and select File > Export or Save as PDF. This process generates a true PDF text layer with embedded character maps.
• The pitfall to avoid: Do not use "Print to PDF" from third-party image viewers or preview software that rasterizes text into graphics before outputting the PDF file.
• The fallback: Optical Character Recognition (OCR) software can recreate text layers on flattened scans, but native exports from a word processor remain the standard approach for job applications.

Once you have a valid text layer with Unicode-compatible font encoding, how do specific characters fare?

#The Controlled Parser Experiment

To measure character preservation directly, we conducted a controlled benchmark on the Career Copilot free parse-check engine on November 2, 2026.

The test utilized a synthetic, clearly fictional profile for Alex Carter, Backend Engineer (featuring an @example.com email address and standard dummy contact details). Four PDF variants were compiled using Python's fpdf2 library with embedded DejaVu Sans fonts to ensure proper Unicode character mapping. Every document kept the identical layout, contact details, summary, and work history, changing only three targeted probe lines:

1. Probe 1 (Languages): Plain ASCII vs. accented international text (Español, Français, and Deutsch (Zürich office)).
2. Probe 2 (Bullet prefixes): Standard hyphens (- ) vs. four distinct glyphs: bullet (• ), en dash (– ), em dash (— ), and right-pointing triangle (▸ ).
3. Probe 3 (Technical skills): Common programming terms containing symbols (C++, C#, .NET, Node.js, R&D, and Q&A).

Before running the API checks, a local text extraction inspection confirmed that each variant's text layer contained its intended probe characters: 1,022 characters for plain, 1,041 for accents, 1,022 for glyph bullets, and 1,019 for special symbols.

Each variant was submitted sequentially to the parse-check endpoint. All four runs returned successful HTTP 200 responses with zero dropped segments.

#Resume Accents, Bullets, Special Characters, and Unicode: What the Parser Saw

The results across all four variants revealed consistent, byte-for-byte extraction on this site's parsing engine.

Variant Comparison Summary (Career Copilot Parser Check)
-------------------------------------------------------------------------------
File Variant    Total Segments    Segment Integrity    Dropped Segments
v_plain         21                21 intact            0
v_accent        21                21 intact            0
v_bullets       21                21 intact            0
v_special       21                21 intact            0
-------------------------------------------------------------------------------

#1. Accented Characters (ñ, ç, ü)

In the accented run (v_accent.pdf), diacritical marks passed through completely intact. The parser returned the language line verbatim:

Languages: English, Español, Français, Deutsch (Zürich office)

The ñ in *Español*, the cedilla in *Français*, and the umlaut in *Zürich* did not corrupt into replacement characters or empty boxes, nor did they break the surrounding words.

#2. Bullet Glyphs (•, –, —, ▸)

Job applicants often worry that decorative bullets cause parsers to merge bullet points into giant, unformatted paragraphs or strip text lines. In the v_bullets.pdf run, all four unique bullet prefixes were preserved at the start of their respective segments:

• • Led migration of the checkout API to an event-driven design
• – Improved PostgreSQL query performance for order history endpoints
• — Mentored two junior engineers on code review and testing practice
• ▸ Documented runbooks for checkout incident response

The parser did not strip the glyphs, replace them with hyphens, or collapse distinct achievements into a single text block. The total segment count remained at 21, identical to the hyphenated baseline.

#3. Special Technical Symbols (++, #, ., &)

Programming languages and technical acronyms frequently rely on punctuation. In the v_special.pdf run, the technical skills block returned verbatim:

C++, C#, .NET, Node.js, R&D, Q&A, Python, PostgreSQL

Symbols such as plus signs, hash marks, leading dots, and ampersands were fully retained. None of the symbols caused token fragmentation, unexpected line breaks, or string truncation.

Furthermore, across all four variants, standard contact fields (email, phone, LinkedIn, GitHub, and location) extracted identically in every run. The presence of non-ASCII characters elsewhere on the page did not disturb the parser's entity recognition.

#What Text Extraction Does—and Does Not—Prove

While these results demonstrate that non-ASCII characters can pass safely through a modern extraction pipeline, it is essential to distinguish between character extraction and downstream search behavior.

1. Parser-Specific Scope: This test measures the behavior of the Career Copilot parser. Different recruiting platforms and third-party parsing tools use distinct extraction libraries, and their performance across character sets can vary.
2. Extraction vs. Query Matching: Extracting a string like C++ or C# into a structured database record does not guarantee how an employer's search index evaluates it. Some database search configurations strip punctuation during indexing, which means searching for "C" might unintentionally retrieve "C++", or vice versa. Preserving the character in the text layer is a prerequisite for matching, but query algorithms handle tokens independently.
3. Vendor Specifics (Greenhouse Recruiting): Applicant tracking systems handle parsing anomalies differently. For example, in Greenhouse Recruiting, an unsuccessful parse does not mean an application is rejected or deleted. Instead, the resume file remains attached to the candidate's profile, and administrative fields must simply be entered manually. Greenhouse notes that certain document layout practices—such as artificial letter-spacing within words or heavy visual graphics—can interfere with automated extraction. However, Greenhouse documentation does not state that accented letters or standard bullet glyphs cause parsing failures.

#Practical Troubleshooting Checklist

If you want to ensure your resume characters survive automated processing without issue, follow these verification steps before submitting your application:

1. Perform the Highlight Test: Open your exported PDF in a standard reader (like Chrome or Adobe Acrobat). Click and drag your cursor over words containing accents or symbols. If you cannot highlight the individual letters, your document lacks a text layer.
2. Run a Clipboard Copy-Paste: Copy a bulleted list and your skills section directly from your PDF viewer and paste them into a plain text editor (such as Notepad or TextEdit). If C++ appears as C++ and Zürich appears as Zürich, your embedded font maps are functioning correctly.
3. Use Standard Export Pipelines: Stick to the native PDF export features in Microsoft Word, Google Docs, or LibreOffice. Avoid online converters that compress or rasterize pages into images.
4. Keep Punctuation Logical: Use standard Unicode characters for dashes and bullets rather than custom icon fonts or embedded SVG images, which often fail to register on the underlying text layer.

To see exactly how a parser reads your text layer, contact information, and skill formatting, you can run your file through the Free Resume Parse Check. The tool is completely free, requires no account or sign-up, and provides an immediate view of the text segments extracted by our parser so you can troubleshoot formatting issues before applying.