Privacy

The file is received in memory, sent to the model provider to be read, and released when the response is returned to your browser. It is never written to disk, never placed in object storage, and never recorded in a database. That is true of every candidate document — a resume, a LinkedIn export — without exception.

A company’s own job description is the one upload that leaves something behind, and it leaves text rather than a file. It is read once so its words can be stored under a name the company chose, and the file goes the same way as every other. It describes a vacancy, not a person.

The report you see exists only in your browser tab. Reloading the page loses it. That is why the report has a “Copy as text” button — there is no copy on any server to come back to.

There is a database. It holds the accounts that can sign in — a company name, a username, and a password stored only as an irreversible hash — and the sign-in sessions those accounts hold, which are deleted when you sign out or when they expire.

It also records each candidate analysed: the name, email address and phone number the document gave, and the employer and job title they held at the time. That is written for every analysis, so a recruiter can attach an offer days later without uploading the resume again, and so a returning candidate is recognised as the same person — a name alone cannot do that, because two people share one constantly. It is not the resume, and it is not the report: neither of those is kept. It is visible only to the company that ran the analysis.

One figure from the report is kept: the match score. When a company analyses a candidate against one of its job descriptions, the resulting score out of 100, which job description it was against, and the date are recorded against that candidate, so the company can see it again on their page without paying to read the document a second time. The reasoning behind the score is not kept — not the summary, not the evidence it quoted, not the gaps it listed — and neither is any other part of the report.

A score is this service’s own reading of what a document evidenced, not a fact the candidate or anyone else recorded, so it is treated more narrowly than an offer: it is never shown to another company, and it is never fed back into an analysis, so no verdict and no later score is reached using an earlier one. Re-analysing the same person against the same role replaces the figure rather than adding to it, so what is held is the most recent reading and not a history. Deleting a job description deletes the scores recorded against it.

It also stores the job descriptions a company writes. Up to fifteen per account: a name for the role and the text of the description. This is the one document this tool keeps, and it is the company’s own — what they are hiring for, in their own words, not anything about a candidate. A description uploaded as a file is read once so that its text can be stored and shown back for correcting; the file itself is released with the request, like every other upload here. No other company can see a job description, search one, or learn that it exists.

It also records a fingerprint of each document analysed — a SHA‑256 hash of the file, which is a fixed-length string of digits and letters that the document cannot be reconstructed from and that reveals nothing about whose it was. It is stored so that uploading the same file a second time asks whether that was meant, rather than quietly costing the company another analysis. It is compared only against the same company’s own earlier uploads, never across companies, and it is not the document: the document is still never written down anywhere. Stored beside that fingerprint is which of the company’s own job descriptions the document was read against, so that a second upload can say which role the first one was for.

Contact details are transcribed from the document and never used to contact anyone by this service. Nothing is emailed, no message is sent, and they exist so that two readings of the same person land on the same record.

Anything a company then records about an offer — the role, the salary, the dates, and what came of it — is kept alongside that candidate. Nothing here is sold, and no advertising or profiling is built on it. A company’s own dashboard shows the median salary it has offered for each of its roles, worked out from its own offers only, in each currency separately, and only once five offers stand behind it. That figure is never shown to another company and never combines offers from more than one.

Offers are visible to other companies using this tool, and the company that made them is named. When a company analyses a candidate, the report shows the offers other companies have recorded for the same person — the name of the company that made the offer, the role, the salary, the date it was made, the joining date, and what came of it. The same offers are shown on that candidate’s page in the company’s own list, so the lookup can be repeated at any time afterwards without analysing the person again. A person is matched only by an email address or a phone number that appears in both records, never by a shared name. Notes a recruiter wrote for their own colleagues are never shown to anyone else.

Said plainly, because it is the part that matters to a candidate: a company can learn which other company has offered you a job, on what money, and when you were due to start — without you telling them, and it can look again whenever it likes. It can do this for anyone it has analysed, and analysing someone is the whole of what it needs: an email address or a phone number for you, and an analysis left in its allowance. It does not need to have met you or to have been sent your CV by you, so being unknown to a company is not by itself protection. It also means that a company recording an offer here is telling the other companies using this tool that it is hiring that person and on what terms. Candidate records themselves are still not shared — each company holds its own, and no company can browse, search, or list another’s. Offer outcomes are never fed back into the analysis, so no verdict is reached using them.

It counts how many analyses each account has run, because that is what the allowance is measured against, and it keeps a note of each analysis while it is running — the account and the time it started, nothing about the document — so that one account cannot start more than a few at once. That note is deleted when the analysis finishes. What remains is a count: how many analyses the account ran on each day against each of its job descriptions, and how many were refunded — never which document, which candidate, or at what time of day.

It records what a company buys. When an account buys analyses, the order is kept: how many, the price, when it was paid, and the payment provider’s reference for the payment. Card and bank details are typed into the payment provider’s own page and never reach this service, so there are none here to keep. A purchase is about the company and its account — nothing about a candidate or a document is sent to the payment provider, and no other company can see what an account has bought.

Server logs record that an analysis ran, which account ran it, how long it took, how many sources and roles were involved, and the confidence of the result. No document content, no candidate name, and no extracted text is written to any log.

The document text is sent to Google, whose model reads it. Nothing else receives it: there is no enrichment provider, no resume database, and no advertising on this site.

This deployment runs against a billing-enabled account, whose terms bar the provider from training on submitted content or having humans review it. Unpaid API tiers generally reserve both rights, and a candidate’s resume is not ours to hand over on those terms.

This site counts page views through Vercel Web Analytics. It records the page addresses visited, the referring site, and a coarse location and device type. It sets no cookies and does not follow you to other sites.

It cannot see an uploaded document or a report. The analysis is one request to the server and the report is drawn in your tab without ever becoming a page address, so there is nothing about a candidate for a page-view counter to record.

The documents you upload describe someone other than you. Only upload a resume or profile you have a legitimate basis to process — a candidate who applied to you, or one who agreed to be considered. Depending on where you and the candidate are, that basis may be a legal requirement, not just good manners.

Resume Trust is decision support for a screening conversation. It reads documents and reports what they say. It does not decide whether to interview or hire anyone, and it should never be the reason a candidate is rejected unread.

If a report affects how you treat a candidate, the report’s evidence — not its verdict — is the part to act on, and the questions it suggests are there so the candidate gets to answer for themselves.