A salary record can omit your name and email while still looking familiar to someone who knows your role.

Fast answer: Levels.fyi says public salary submissions do not include the submitter’s name or email. That does not guarantee complete anonymity: employer, role, level, location, experience, and free-text notes may combine into clues. Check the record before submitting. A separate registration email can limit exposure of your contact address, but it cannot make the salary details anonymous.

This guide is for students and job seekers deciding whether to submit compensation information to Levels.fyi, and for tech workers weighing how recognizable a public record might be.
It also helps people who only want to browse salary data distinguish account registration details from information they choose to submit.

Check what “anonymous” means for a Levels.fyi salary submission

“Anonymous” can describe more than one thing. In this case, separate two layers:

  • Account contact information: Details associated with the account and handled by the service. The Levels.fyi signup page is the place to check the current account-registration and email-verification flow.
  • The public salary record: Information that may appear when a submission is published. Levels.fyi’s privacy policy says a public salary submission does not include the submitter’s name or email.

That distinction matters. “Name and email are not shown with the public record” is a statement about what is displayed, not a promise that the service does not process account data. It is also not a promise that other details in the record cannot point to a person.

The policy also warns that combinations of details, such as employer, job, level, and location, may allow someone to infer an identity. This is the central privacy boundary: the account email may be absent from the published record while the record itself still contains recognizable context.

The policy is marked effective September 22, 2026. Check the current policy and the submission screen before acting, because the page and interface in effect at the time of submission are the relevant references. This reading does not extend the policy into a stronger promise than it makes.

Key takeaway: No name or email on a public record does not mean no identifying clues in the record.

Assess how job details combine into identity clues

A single field can look broad. A combination can be much more distinctive. An employer name might describe a large organization; a job title might be used by many people; a location may cover a wide area. Add a rare level, a narrow team description, unusual experience details, and a recent career event, and a colleague may have a much smaller group of people in mind.

Consider a hypothetical case. A submission identifies a particular employer, a specialized role, a seniority level, a specific office location, and an uncommon career path. None of those details has to name the submitter directly. But a person familiar with that office could connect them to a colleague, especially if the person already knows who recently changed roles.

This example illustrates a possibility, not a claim that every combination will identify someone. The platform policy itself flags the risk of inference from combined details; it does not provide a universal recognition probability. Avoid treating a single broad field as the whole privacy assessment.

A useful way to review a record is to imagine three readers:

  • A stranger: Can they identify a person from the published fields alone?
  • A colleague: Do they know the team, level structure, office, or recent hiring changes?
  • A manager or recruiter: Could they connect the details to information already available in workplace systems or public profiles?

The same record may appear low-risk to a stranger and much more recognizable to a coworker. If coworkers are the audience you most want to protect against, review the details from their perspective—not only from the perspective of someone browsing the site without background knowledge.

This is why salary data privacy depends on more than the contact email. The email question is straightforward to check in the policy. The harder question is whether the remaining fields reveal enough context to narrow down who submitted the record.

Inspect free-text notes before submitting

Structured fields are only part of the record. A comment or note can add identifying information that is easy to overlook because it feels like context rather than a formal field.

Before submitting, read every free-text entry as if it will be shown exactly as written. Look for:

  • A name, email address, phone number, or social profile.
  • A team, project, office, or manager name that narrows down the group.
  • A precise description of a promotion, transfer, interview, or unusual work event.
  • A personal timeline that could connect the submission to a known colleague.
  • Phrases that quote internal language or describe non-public circumstances.

Do not rely on an imagined automatic cleanup process. The policy and interface should be treated as the authority on what the service says it does. Unless the current official description clearly promises a specific review or removal process, assume the submitter is responsible for checking what they enter.

A short note can still contain a strong clue. For example, a generic compensation comment may be less identifying than a sentence describing a small team’s recent reorganization. The important question is not whether a detail seems sensitive by itself; it is whether it adds context to the rest of the record.

If the form makes a field optional, leaving it blank can be safer than adding detail that does not materially improve the information. If the field is required, use only information that is accurate and that the submitter is comfortable having associated with the published record under the platform’s stated rules. Do not invent a different identity or submit misleading details as a privacy tactic.

Evaluate the privacy-enhancing setting without treating it as a guarantee

Levels.fyi’s privacy policy describes an optional privacy-enhancing setting. The policy indicates that it may hide or generalize some fields. That can reduce exposure from the fields it affects, but it does not establish that every record qualifies, that every identifying clue disappears, or that the resulting record is impossible to recognize.

Before relying on the setting, check the current submission interface and the wording shown for that specific submission. Confirm whether the option is available, what the interface says it changes, and whether the record preview reflects that change. If a setting is not visible or its effect is unclear, do not assume it is active.

Even when a field is hidden or generalized, other details may remain. A broader location, for example, does not remove a distinctive role description or a revealing comment. Likewise, an option that changes how certain fields appear cannot correct identifying information typed into free text unless the interface explicitly says it does.

The privacy setting is best understood as a possible reduction in exposure, not as a substitute for reviewing the record. A de-identification reference from NIST on de-identifying data sets is useful for the wider principle: removing direct identifiers does not by itself settle every risk created by the remaining data. That general guidance does not describe the specific behavior of the Levels.fyi setting, so use the platform’s own policy and submission interface for that.

Choose whether to submit based on your exposure limit

Use these decision conditions before filling out the form:

  • If the only concern is your registration email appearing beside the public record, check the current privacy policy and submission flow. Levels.fyi says the public salary submission does not include the submitter’s name or email. Keep in mind that this addresses display of those details, not all handling of account information.
  • If you are comfortable sharing the compensation information but not every job detail, review which fields are required, remove unnecessary detail from optional fields, and check the privacy-enhancing setting if it is available. Proceed only if the remaining record fits your exposure limit.
  • If your workplace is small or your role and career history are distinctive, assess the combined fields from a coworker’s point of view. If the remaining combination could readily narrow the identity, leave out optional clues or do not submit.
  • If the form permits free-text notes, remove names, contact details, team identifiers, and unusually specific events. If the note adds no useful context, omit it.
  • If you cannot accept the possibility that detailed job information could be linked back to you, do not submit the record. Browsing salary information and submitting a record are different actions; choosing not to contribute does not require sharing your compensation details.
  • If you are considering a separate email address as the solution, treat it only as a way to separate registration contact details. It does not change the employer, role, level, location, experience, or comments in the salary record.

This framework keeps the decision tied to the information being shared. It avoids two unhelpful extremes: assuming that the record is fully anonymous because the email is absent, or assuming that every submission necessarily identifies its author. The actual question is whether the record’s remaining detail is acceptable to the person submitting it.

Separate email exposure from salary-record exposure

A separate address can be useful when a service registration is not meant to use the main inbox. It can reduce the number of places where the primary address is entered and help keep unrelated registration messages apart. It cannot alter the salary information that a person voluntarily submits, and it cannot guarantee that a platform will accept a particular type of address.

The OrbSend privacy guide explains the broader boundary between reducing email exposure and protecting information contained in a submission. That distinction applies here: account-contact privacy and record anonymity are separate decisions.

Email forwarding also solves a different problem. It can route incoming messages from a separate address, depending on the service and settings in use; it does not hide or generalize salary fields. The OrbSend forwarding information may help readers assess that email-management option, but forwarding should not be mistaken for a way to anonymize a public record.

If a separate registration inbox suits the reader’s needs, OrbSend offers a way to keep a registration address apart from a primary inbox. Use that only for the contact-address layer. The decisive privacy check remains the same: inspect the fields, remove identifying notes, and decline to submit if the remaining details fall outside the acceptable exposure limit.

Complete a final review before submitting

Use this sequence at the form, not from memory:

  1. Check the current policy. Confirm what Levels.fyi says about public salary submissions and account information. Use the current official policy rather than relying on an old summary.
  2. Review the record fields. Look at employer, role, level, location, experience, and any other details included in the current form. Ask whether the combination is more distinctive than each field alone.
  3. Read every note aloud. This can make names, team references, unusual events, and personal timelines easier to notice. Remove details that are unnecessary or that the submitter would not want associated with the record.
  4. Check the privacy option. If the interface offers a privacy-enhancing setting, verify its current description and the result shown in the form. Do not infer effects that are not stated.
  5. Consider the likely audience. Test the record against what a coworker or recruiter might already know, not only what a stranger could infer from the public page.
  6. Make the stop-or-submit decision. If the remaining record still exceeds the acceptable exposure limit, do not submit. Changing the registration email is not a substitute for this decision.

This is also a useful distinction for people who only want salary data. Viewing a public record does not, by itself, mean that a person must contribute their own compensation information. Check the account requirements for browsing separately, and do not submit data simply because a service asks for it during a different action.

Frequently asked questions

Does Levels.fyi show my email with a published salary submission?

Levels.fyi’s privacy policy says the public salary submission does not include the submitter’s name or email. That statement concerns what is attached to the public record. It does not mean account details are never processed by the service, so review account information and public-record display as separate issues.

Could a coworker recognize a salary record without seeing my name?

Possibly. Employer, role, level, location, experience, and free-text details may form a recognizable combination for someone with workplace context. A broad field may seem non-specific alone, but the full set can narrow the possibilities. There is no universal recognition probability; the submitter has to judge the context and remaining detail.

What should be removed from a salary submission?

Review the structured fields and any notes. Remove names, contact information, team identifiers, and highly specific descriptions of personal or workplace events when they are not necessary. Check the entire combination rather than judging each item separately. Do not assume an automated system will identify or remove details that could point to the submitter.

Does the privacy-enhancing option make a submission anonymous?

No absolute guarantee follows from the policy’s description of an optional setting that may hide or generalize some fields. Check the current interface to see whether the option is available and what it says it affects. Then assess the information that remains. If that residual detail is not acceptable, do not submit.

Before sharing compensation information, the safest approach is to decide what level of detail is acceptable and stop if the finished record exceeds it. A separate registration address can help keep the primary inbox from being exposed to another service, but it cannot change the record’s identifying clues. If the concern is limited to registration email separation, OrbSend is one option to consider; if the concern is the salary content itself, revise the details or choose not to submit.

Frequently asked questions

Does Levels.fyi show my email when it publishes a salary submission?
Levels.fyi’s privacy policy says a salary submission, when made public, does not include the submitter’s name or email. That describes what appears with the published record; it does not mean the service never processes account information. Treat your account contact details and the salary record as separate privacy layers, and review the current policy and submission screen before sharing.
Could a coworker recognize my Levels.fyi salary record?
Possibly. A public record may omit your name and email yet still contain a distinctive combination of employer, role, level, location, experience, or compensation details. Someone who already knows your team or career history may connect those clues. There is no reliable way to assign a universal chance of recognition, so assess the combination from the perspective of someone familiar with your workplace.
Which job details should I review before submitting salary information?
Review the employer, job title, seniority or level, location, experience details, and every free-text note. A broad title or location may seem ordinary on its own, but uncommon details can become identifying when combined. Remove names, contact information, team labels, and unusually specific career events from notes. Do not assume the platform will automatically detect or delete identifying details.
Does the privacy-enhancing setting guarantee an anonymous submission?
No. Levels.fyi describes an optional privacy-enhancing setting that may hide or generalize some fields, but that is not an unconditional anonymity guarantee. Its effect may depend on the submission and the available settings. Check what the interface says for the specific record, then assess any details that remain visible. If that residual exposure is unacceptable, do not submit the record.

Leave enough time for your next verification

Create a temporary email that starts with 3 hours and can be extended when needed.

Create a temporary email