Every job seeker has heard the same warning: "your resume might not even reach a human, an ATS could filter it out first." I heard it enough times from friends applying abroad that I decided to actually build the thing and see what it does under the hood, instead of taking the warning at face value.
That side project turned into the ATS Resume Checker inside AsliCV, a resume and cover letter builder I run alongside my full-time job as a full stack developer. This post is less "look at my product" and more "here's what I learned building a keyword-matching tool that has to work on messy, real-world PDFs" — the kind of resumes people actually upload, not the clean sample files every tutorial uses.
The problem looked simple. It wasn't.
The pitch sounds easy: take a resume, take a job description, compare the words, return a score. In practice, three things made this harder than expected.
PDFs lie about their own text. A resume that looks like clean text to a human can be an image wrapped in a PDF container, with zero extractable text underneath. Scanned resumes, resumes exported from design tools, resumes photographed and converted — all of them pass the "it's a PDF" check and fail the "there's actually text in here" check. Early versions of the tool returned a 0% match on perfectly good resumes simply because there was nothing to read. The fix wasn't a smarter matching algorithm — it was validating text extraction before running any comparison at all, and telling the user clearly when a file has no readable text instead of silently scoring it as a bad match.
Keyword matching without context is close to useless. A naive approach — split both documents into words, count overlaps — technically works, but it treats "managed a team of five" and "team management" as unrelated, and it treats "Python" appearing once in a skills list the same as "Python" appearing in three years of job titles. Getting a match score that felt honest meant weighting where a term appears, not just whether it appears, and handling variants — acronyms versus long-form phrasing, plurals, common synonyms — as the same signal instead of separate misses.
Formatting problems are invisible to the person who made them. Tables, multi-column layouts, and text boxes look fine in a PDF viewer but can scramble the reading order an ATS extracts — a two-column resume can come out as one sentence spliced from both columns. This one surprised me the most, because it means the resume can be well-written and still score poorly for reasons that have nothing to do with the words on the page.
The stack, briefly
Next.js on the frontend, with the parsing and matching logic running server-side rather than in the browser — partly for reliability across file types, partly to keep the comparison logic out of client-inspectable code. PDF text extraction, then a matching layer that scores keyword overlap, flags structural red flags (tables, columns, non-standard headings), and returns a breakdown instead of just a single number. The whole thing had to run in a few seconds with no login, because friction kills usage for a free tool — if someone has to make an account before finding out their resume is broken, most people just leave.
What surprised me building this
The most common cause of a low score wasn't bad writing. It was formatting choices that looked good — a photo, a skills sidebar, a colored header — that an ATS reads as noise or, worse, ignores entirely. I ended up adding a plain-language explanation for every flag, because "formatting issue detected" tells a job seeker nothing they can act on, while "this table layout may cause your work history to be read out of order" does.
The second surprise was scope of audience. I built and tested this against resumes from Afghan and diaspora job seekers applying across the UK, Germany, Canada, the US, and Australia — non-Western name formats, mixed-language education entries, career gaps that don't fit a single narrative arc. Most existing checkers are clearly tuned against a fairly narrow template of resume. Testing against a wider variety surfaced edge cases those tools probably never see in their own QA.
Try it
The checker is free, doesn't require sign-up, and gives you the same breakdown described above: match percentage, missing keywords, and formatting flags. You can try it at aslicv.com's ATS Resume Checker.
If you're building anything that parses user-uploaded documents, I'd genuinely like to compare notes — PDF text extraction has more edge cases than any tutorial prepared me for. Happy to answer questions about the matching approach in the comments.
Top comments (0)