layiq
worthy; deserving; fitting; suitable.
A role, opportunity, or path that merits attention, time, and pursuit.
Loading LAYIQ…Runs in your browser. Your file is never uploaded or saved.
Choose a PDF or DOCX and see the plain text a straightforward parser takes from it, which fields it can find, and what to change. There is no account, no email gate and no score to chase.
Last updated
Drop your résumé here
PDF or DOCX, up to 10 MB. English-language résumés.
Runs in your browser. Your file is never uploaded or saved.
It lists the skills and tools a posting names and shows which ones your résumé uses and which it does not, with a count of the terms found. It compares words only: it is a list of terms found and missing, not a match score.
Paste the posting’s text. Once your résumé is chosen, the comparison appears in your report. The posting stays in this tab, like your file.
0 of 20,000 characters
The report shows the plain text a parser takes from your file, the fields a reference reader finds in that text, and a list of checks. Each check shows evidence from your file, what to do about it, and whether its concern is documented or is common advice. If you paste a job description, the report also lists which of its terms your résumé uses.
jordan-ellis-resume.docx · DOCX · about 1 page · 163 words
The line marked header is text from the page header, which some parsers skip.
Document order
[header: jordan.ellis@example.com | (512) 555-0142] Jordan Ellis Senior Product Manager Austin, TX EXPERIENCE Senior Product Manager, Northwind Pay Mar 2021 – Present Led the redesign of merchant onboarding across web and mobile Set up weekly experiments with engineering and analytics Wrote the quarterly roadmap and reviewed it with finance, support and sales Worked with six engineers and two designers on payment settings Presented launch plans and results to the leadership team each quarter Mentored two associate product managers and ran their quarterly reviews Product Manager, Northwind Pay Jun 2018 – Feb 2021 Owned the invoicing product from first prototype to general release Interviewed merchants every month and turned what they said into requirements Wrote specifications and acceptance criteria for each release Trained the support team on new features before every launch Ran a pilot with a small group of merchants before the full release Simplified the setup screens so fewer merchants needed help from support EDUCATION B.A. Economics, State University, 2018 SKILLS SQL, Figma, Jira, A/B testing, roadmapping
The reader looks in that text for the fields an ATS usually fills in. Where it finds nothing, it says “Not found”.
| Field | Found |
|---|---|
| Name | Jordan Ellis |
| jordan.ellis@example.com (only in the header or edge of the page) | |
| Phone | (512) 555-0142 (only in the header or edge of the page) |
| Location | Austin, TX |
| Not found | |
| Section headings | EXPERIENCE · EDUCATION · SKILLS |
| Jobs with dates | Senior Product Manager, Northwind Pay (Mar 2021 – Present) Product Manager, Northwind Pay (Jun 2018 – Feb 2021) |
| Skills | SQL, Figma, Jira, A/B testing, roadmapping |
Each check says what it found in the file, what to do, and where the concern comes from.
Header and footerFix thisLayout
Some contact details appear only in the page header or footer. A parser may skip that area and never see them.
From your file
What to do
Put your name, email and phone number in the main text at the top of the first page, not in the header.
Jobs and titlesLooks fineWhat a parser finds
A title and an employer could be matched to 2 of 2 date ranges.
From your file
Employers use many different applicant tracking systems, set them up in their own ways, and keep those settings private. No outside tool can reproduce what one employer’s system would do with your file, so a single score would claim a precision that nobody outside that system has.
This checker shows what a straightforward parser extracts instead: the text, the fields it found and did not find, and the evidence behind each check, so you can judge for yourself. A clean report does not mean any employer’s system will read your file the same way, and it says nothing about whether you match a job.
An applicant tracking system (ATS) is the software an employer uses to collect and manage applications. When you upload a résumé, it usually tries to read the file into fields: your name, contact details, jobs, dates, education and skills. Recruiters then search and sort those fields, and they can usually open your original file as well.
How well that reading goes depends on the file. Plain text in a single column is easy to read. Text locked in an image, a table or a text box can come out missing or in the wrong order, and a profile built from that may be harder to find.
A formatting problem is not the same as an automatic rejection. For what is documented about rejection, and where the claim that an ATS throws out most résumés comes from, read Does an ATS reject your résumé?
For the changes worth making to your file, and the advice that is not worth following, read ATS-friendly résumé: what to change and what to skip.
Each check shows evidence from your own file and says what to do about it. Some apply to one file type only. The last column says where the concern comes from.
| Check | What we look at | Why it matters | Basis |
|---|---|---|---|
| File type | Whether the file really is a PDF or a DOCX, whatever its name says. | Applicant tracking systems accept a short list of file types; Greenhouse, for example, takes .doc, .docx, .pdf, .rtf and .txt. Photos and scans may be refused or read as blank, and this checker reads PDF and DOCX only. | Documented |
| File size | How large the file is. | A large file usually means embedded images or fonts, and some application forms cap upload size. | Convention |
| File name | Whether the name tells a recruiter whose résumé it is. | Recruiters see the name when they download your file. It does not change how the text is read. | Convention |
| Copy protection (PDF only) | Whether the PDF asks readers not to copy its text. | A parser that honors that setting may not be able to take the text out of a protected file. | Convention |
| Length | Pages and word count. | Most résumés fit one or two pages. Longer ones are fine when the experience is there. | Convention |
| Check | What we look at | Why it matters | Basis |
|---|---|---|---|
| Selectable text | Whether every page holds real text rather than a picture of text. | A parser reads text, not pixels. A page that is only an image may read as blank, and this tool does not do OCR. | Documented |
| Readable characters | Characters that did not turn into readable text, such as replacement marks, icon-font glyphs and joined letters like “fi”. | Unrecognized characters are a documented reason a résumé fails to import cleanly, and they can break keyword matching. | Documented |
| Symbols and icons | Decorative symbols, emoji and arrows in the text. Plain bullets are fine. | Symbols may drop out or turn into odd characters when a parser reads the file. | Convention |
| Fonts and size | How many font families the file uses and how small the body text is. | Many fonts or tiny type make a résumé harder to read for people and, sometimes, for software. | Convention |
| Hidden text (DOCX only) | Text marked hidden, set to 1 point, or colored white on a white page. | A parser may read text a person cannot see, and a hidden keyword list can look like stuffing. | Convention |
| Tracked changes and comments (DOCX only) | Leftover edits and comments stored in the file. | A parser may read deleted wording or comments as part of your résumé, and a recruiter who opens the file can see them. | Convention |
| English text | Whether the text reads as English. | The checks and the reference reader here are written for English-language U.S. résumés. | Convention |
| Check | What we look at | Why it matters | Basis |
|---|---|---|---|
| Columns | Whether the page is laid out in side-by-side columns. | Some employer guidance asks for a single column, because a parser may read across the columns instead of down them. | Documented |
| Tables (DOCX only) | Text laid out in table cells. | A parser may read a table row by row and mix the cells together. Some employer guidance says to avoid tables. | Documented |
| Text boxes (DOCX only) | Text placed in floating text boxes. | Text boxes sit outside the main flow of the page and may be skipped or read out of order. Employer guidance says to avoid them. | Documented |
| Header and footer | Contact details that sit only in the page header or footer. | Some parsers skip headers and footers, and employer guidance says to keep key details out of them. | Documented |
| Images and graphics | Photos, logos and other picture content. | A parser cannot read text inside an image, and a photo gives it nothing to use. Employer guidance says to avoid logos and images. | Documented |
| Links | Whether each link shows its address in the visible text. | A parser that reads text sees the words on the page, not the address behind them. | Convention |
| Check | What we look at | Why it matters | Basis |
|---|---|---|---|
| Name | Whether a name can be read at the top of the first page. | The name is the first field a parser looks for, and missing information is a documented reason an import fails. | Documented |
| Email address | Whether an email address can be read. | Without an email address there is nothing for an employer to reply to, and missing information is a documented reason an import fails. | Documented |
| Phone number | Whether a phone number can be read. | Many application forms ask for a phone number, and a parser may fill it in from your résumé. | Convention |
| Location | Whether a city and state appear with your contact details. | Recruiters often filter by location, and a parser may fill it in from your résumé. | Convention |
| Profile links | Whether a LinkedIn address is written out in the text. | A link only counts for a text reader if its address is written on the page. A profile link is optional. | Convention |
| Section headings | Whether standard headings such as Experience, Education and Skills are used. | Parsers sort your text by looking for familiar headings. Uncommon headings can leave content unfiled. | Documented |
| Dates | Whether jobs have dates and how the dates are written. | A parser works out your experience from the dates it can read. Mixed or unusual formats are harder to read. | Convention |
| Jobs and titles | Whether each date range sits next to a job title and an employer. | When dates drift away from titles, a parser may build the wrong work history. | Convention |
| Skills list | Whether a skills section lists your skills as separate items. | Many systems look for skills in a labeled section. A list is also easy for people to scan. | Convention |
The guide Does an ATS reject your résumé? lists the sources behind the documented checks. Checks marked convention are labeled that way so you can weigh them yourself.
The analysis happens locally in this browser tab. Your file is read by code that runs on your device, and nothing is sent to LAYIQ: no upload, no copy of your file or its text, and no copy of your results.
Nothing is saved. The file, the text taken from it, the report and any job posting you paste live only in the memory of this tab. Closing or reloading the page clears them.
PDF files are read by pdf.js, an open-source library from Mozilla that runs in your browser and loads from LAYIQ’s own site. DOCX files are read by code written for this page. Neither sends your file anywhere.
You can check this yourself. Open your browser’s network panel, choose a file and watch the requests: the only ones are for the checker’s own code, and none carries your file.
It shows how software that reads résumés may see your file. This one takes the text out of your PDF or DOCX, lists the fields a simple parser can find, such as your name, email, jobs and dates, and runs checks for layout problems that can scramble that text, such as columns, tables, text boxes and images. It does not predict whether you will get an interview.
Not in the sense of a pass-or-fail scan. It reads your PDF or DOCX the way a straightforward parser might and shows you the text it took, the fields it found and the layout problems that can scramble them. It is not any employer’s ATS and it gives no score, because real systems differ from one another and from this reader. ATS-friendly résumé: what to change and what to skip covers what to change in your file.
No. The checker runs in your browser and reads your file on your device. Nothing is sent to LAYIQ and nothing is stored, so closing the tab clears it. A job posting you paste to compare stays in the tab too. The privacy section explains how to confirm this yourself.
Usually not. Formatting problems more often mean a system fills in your profile wrongly or leaves parts empty, which can make you harder to find. The automatic rejections that are documented come from rules the employer sets, mostly screening questions on the application, not from how a résumé looks. The evidence is in Does an ATS reject your résumé?
Use the file type the application asks for. If both are allowed, either usually works as long as the text is real, selectable text in a simple layout. Employer guidance differs on which parses best, so this checker reads both and shows what each file gives a parser. A PDF exported from your word processor keeps its text selectable. A PDF made by scanning or printing to an image does not.
A parser reads a file as a stream of text. When a page has side-by-side columns, some parsers read straight across the page and mix the columns together. Tables and text boxes may be read cell by cell or skipped, and some employer guidance asks candidates to avoid them. When the checker finds columns it shows the text in more than one reading order so you can see the difference.
No. One number would suggest a precision that nobody outside an employer’s own system has. You get the extracted text, the fields found, and each check with its evidence and a fix. Each check also says whether its concern is documented by an ATS vendor or an employer, or is common advice.
No. The checker does not do OCR, which turns pictures of text into text. A page that is only an image reads as blank to a parser, so the checker reports it as a problem to fix. Export a text-based PDF from your word processor, or retype the résumé, and check that file.
If you paste a job description, the checker pulls out the skills and tools it names, notes which are listed as requirements and which as nice to have, and shows how many of those terms appear in your résumé. It compares words only. It is not a match score and it does not know what is true for you. Add a term only if it is true for you.
It depends on the file and on the employer’s system, and no tool can tell you for certain how a particular employer’s system will read it. What you can check is how a straightforward parser reads your file. A résumé tends to read more cleanly when it is real, selectable text in one column, with your name and contact details in the main text, standard headings such as Experience and Education, and dates written one way. Choose your PDF or DOCX above and the checker shows the text a parser takes, the fields it finds, and each check with its evidence and a fix.
A résumé parser is software that reads a résumé file and tries to sort its text into fields such as your name, contact details, jobs and dates, education and skills. Applicant tracking systems usually include one, and recruiters then search and sort by those fields. Parsers differ from one another, so this checker uses its own reference reader. It shows the plain text it takes from your PDF or DOCX and the fields it finds in that text, so you can see what a straightforward parser gets and what it leaves out.
The checker itself uses the internet only to download its own code. Your browser gets that code from LAYIQ’s site, some of it when the page opens and the rest the first time you choose a file. A PDF also loads pdf.js, the open-source reader from Mozilla, from the same site. Those are downloads of code. Reading your file, running the checks and comparing a posting happen on your device, and the checker sends nothing that carries your file, its text or your results. Other parts of LAYIQ’s site, such as page analytics, make requests of their own. Because part of the checker loads when you first choose a file, we do not promise it works with your connection turned off. The privacy section says what stays on your device.