LinkedIn to Resume, by CVGist is Chrome extension, not advice about adding LinkedIn to a résumé. It is a cvgist.com product (store developer site: mycvcreator.com), with 10,000 users, v0.1.8, MV3, and a store listing updated 2025-12-02.
My August 2026 line-by-line read gives it a Low-risk verdict, with four residuals:
the ext_id is on LinkedIn's AED probe list, though the shipped build declares zero web-accessible resources, so the reachability of the probe file that listing names is inferred from the manifest, not observed;
a content script runs on every LinkedIn page, passive until the popup fires it;
three isTrusted=false programmatic clicks hit LinkedIn's own controls;
a full profile PDF crosses to cvgist.com, where this audit stops.
The important result is simpler: the extension never reads the LinkedIn session, and the session never leaves the browser.
The six-step code path
1. Load: declare two narrowly placed content scripts
text ://.linkedin.com/* https://cvgist.com/resume-from-profile/generating
The LinkedIn script loads on every LinkedIn page but remains passive until the popup triggers it; the other script is limited to CVGist's generating page.
What this means for detection: AED is the documented signal here; Spectroscopy and the page-snapshot worker are unavailable findings, because I found no injected element, script, style, iframe, or chrome-extension:// resource for either scanner to find.
AED, or “Active Extension Detection,” is not an official public name or my coinage: it is the label in LinkedIn's production JavaScript, where results ship as an AedEvent. BrowserGate, an independent 2025–26 investigation that took apart LinkedIn's production bundle, documented it, as did Linked Helper's security study, whose scope was static audits of 16 extensions plus live two-account sign-up tests of seven cloud tools. LinkedIn has never publicly acknowledged it.
The list grew from 38 entries in 2017 → ~461 in 2024 → 5,459 in December 2025 → 6,167 in February 2026, roughly 12 new entries per day. This ID is listed with icons/icon.png; however, v0.1.8 declares zero web-accessible resources, so I infer that this particular fetch should not resolve. I did not run LinkedIn's scanner. Presence on a list is a signal, not enforcement.
2. Read: parse the public vanity slug
js m.split("/in/")[1].split("/")[0]
That string split reads the public /in/your-name handle already in the address bar. It becomes the extension's userId; it is not a token.
What this means for detection: no independent detection signal at this step — a string split on a URL already in your address bar produces no request, no header, no traffic.
3. Click: drive LinkedIn's own control
js .click()
The shipped source contains three .click() call sites (content-scripts/linkedin.js:40, :42, :123) covering “More” and “Save to PDF.” These are occurrence counts, not observed events; there is no loop, queue, timer, invite, message, or generated profile visit.
What this means for detection: programmatic clicks have read-only isTrusted=false, unlike a human click; normal extension APIs cannot forge true, while chrome.debugger exposes a permanent debugging banner. Linked Helper's security study says this was not yet mass-enforced at the expert's last direct knowledge, but described wider use as “a matter of time.”
4. Intercept: catch LinkedIn's PDF
js fetch(n.url)
chrome.downloads.onCreated catches an application/pdf from LinkedIn, cancels the native download, re-fetches that issued URL, base64-encodes the blob, and stores it locally as linkedInProfilePDF alongside linkedinProfileId (background.js:48–55).
What this means for detection: no documented request-map-anomaly signal applies — the profile page and its surrounding traffic produced the PDF URL normally. A second GET is an oddity, but none of my sources identifies it as a detection vector.
5. Hand off: cross the vendor boundary
text chrome.storage.local window.postMessage
The worker opens https://cvgist.com/resume-from-profile/generating; its content script retrieves the PDF and public slug from local storage and posts them into that page.
What this means for detection: LinkedIn cannot observe a postMessage inside a CVGist tab; this is a privacy boundary, not a LinkedIn detection signal. What CVGist's web app does next is outside this audit.
6. What never happens
json "permissions": ["downloads", "storage", "tabs"]
There is no cookies permission, , externally_connectable, declarativeNetRequest, telemetry endpoint, WebSocket, XHR, sendBeacon, remote queue, or background timer. The only credentials:"include" occurrence belongs to React's generic module preloader, not LinkedIn.
What this means for detection: the unavailable vectors are the finding — no session replay means no APFC fingerprint or IP/parallel-session comparison, no API call means no request-map anomaly, and no injected artifact means no Spectroscopy or page-snapshot claim.
Here are the four reproducible searches I ran across the shipped, beautified source:
text rg "chrome\.cookies|browser\.cookies" → 0 matches rg "li_at|JSESSIONID|\bli_a\b" → 0 matches rg "document\.cookie" → 0 matches rg "csrf-token|x-restli|voyager" → 0 matches
These are static counts of pattern occurrences in shipped source, not a claim that I observed zero traffic at runtime; they foreclose session replay, direct LinkedIn API access, and the corresponding fingerprint/request-map vectors in this build.
The practical caveat starts with LinkedIn's own limits
Because this extension drives LinkedIn's first-party button, it inherits that button's constraints. LinkedIn says: “Profiles must be in English, and the member's language setting must also be English”; “This feature is not available on the LinkedIn mobile app”; “The Save to PDF option currently supports only English characters”; and “You're limited to 200 PDF downloads per month.” I fetched LinkedIn's Help Center page on 2026-08-31.
That ceiling is why there is no credible volume story here. The dependency is still qualitative: this is a first-party button LinkedIn has changed before.
No live IP test was run, and there is nothing for one to measure: there is no cloud tier, vendor login, or server-side session, hence no exit IP, ISP, ASN, or fingerprint comparison.
What this means for your account
It is a scoring model, not a tripwire. Each signal adds points; a listed extension ID and three synthetic click sites are two small additions, and safe daily limits do not offset a detectable architecture in either direction. What this build contributes is close to the floor: no connection requests, no messages, no profile-visit runs, no background timers, and a ceiling LinkedIn itself sets at 200 profile PDFs a month.
A smaller surface is still not immunity. This extension exposes less than almost anything else I have taken apart, and it still exposes something — an ID on a list and three clicks a page script can tell apart from yours. The behavioural layer also judges humans and robots alike: one job seeker had Easy Apply paused after five manual clicks, with no automation involved at all. No tool is unbannable.
What users say about the category
Checked 2026-08-31, the labeled corpus contains zero reviews and zero Reddit posts about this brand. The following are category-level voices about LinkedIn extensions and detection generally; this isn't about LinkedIn to Resume — it is about the category people file it under.
“stop using chrome extensions for scheduling. i've had multiple clients get banned using tools like Taplio. linkedin detects them and flags your account.”
— r/SaaS.
The author also plugs his own SaaS, so the claim has a conflict of interest. My narrower reaction: this product's ID is listed, but detection and enforcement are different facts.
“the mechanism matters less than the behavioral signature. i've seen standalone browser tools get accounts flagged within a week because someone ramped volume too fast - 0 to 150 actions/day doesn't look human regardless of what's driving it.”
— r/b2bmarketing.
He is partly right: clean architecture is not immunity. Here, however, LinkedIn's 200-PDF monthly ceiling removes his ramp-volume scenario, while AED membership remains.
“LinkedIn actively bans accounts caught using automation.”
— r/SaaS.
That flat belief is useful context, not evidence against this product. My read is a scoring model: listed presence and synthetic clicks add signals; neither is an automatic restriction.
FAQ
Is LinkedIn to Resume safe to use on LinkedIn?
My static read rates v0.1.8 Low risk, with the four residuals named at the top. It touches zero leads, connections, or messages.
Does it read my LinkedIn session cookie (li_at)?
No. It lacks cookies permission, and the session-related searches return zero occurrences.
Does LinkedIn to Resume collect user data?
The concrete payload is the full profile PDF plus the public /in/ vanity slug. The extension passes both into a cvgist.com page through local extension storage and postMessage; what that web app subsequently does is outside this audit.
Does LinkedIn detect it?
The ext_id is on AED's target list. Inferred nuance: v0.1.8 exposes no web-accessible resource, so the named icons/icon.png probe should not resolve; I did not test the live scanner.
Can it get my account restricted?
No tool can promise otherwise. This build adds two LinkedIn-facing signals—listed presence and synthetic clicks—but no automation cadence. Detection is not enforcement.
Are there usage limits?
Yes: English profile and language settings, desktop only, English characters only, and 200 PDF downloads monthly.
Does it scrape LinkedIn's API or send messages?
No. The API/CSRF searches return zero, and there is no queue or code for connections or messages.
Why might the result resemble LinkedIn's PDF?
Before CVGist processes it, it is LinkedIn's PDF. Aggregator summaries of store reviews mention resemblance to LinkedIn's export, unwanted AI rewriting, and omitted sections such as projects; those are summaries, not reviews I read.
The full line-by-line audit, with code citations, is here: https://safe-outreach.com/is-linkedin-to-resume-safe
Top comments (0)