How the privacy-preserving comparison works
Two people, one private room, and a result that reveals only what's needed — enforced on the server, not just hidden in the interface.
BallPark runs on one engine with two flows. Peer comparison tells two people whether their pay ranges are higher, lower, or the same. Expectation check tells a proposer and a responder whether their ranges overlap before they talk numbers. Both flows share the same shape: a private room, one submission per person, and a result that's computed — and restricted — on the server.
Two flows, one engine
Peer comparison is for direction, not overlap: you and one other person each pick a pay range at the same step size, and the result tells you only whether your range is higher, lower, or the same as theirs — never their range, and never how far apart you are.
Expectation check is for alignment before a conversation: a proposer sets a proposed range, a responder enters their expected range, and the result shows whether the two overlap, expressed as a match status (and, for the responder, a match percentage). If there's no overlap, both sides see the gap in coarse steps — not the exact difference.
What happens when you create a room
There are no accounts. Creating a room issues a private link built around an opaque room token — not a database ID you could guess or increment — and a separate participant token stored in your browser that lets you reopen the room as yourself. Anyone with the link can join as the other participant; only two people can be in a room, and each role (creator, responder) can submit exactly once.
Rooms expire after about a week. Past that point the link stops resolving — there's no lingering “reopen an old comparison” feature.
What gets compared, and what doesn't
In peer comparison, only your chosen range is stored on the server; the number you might type to help yourself pick a range is never transmitted or saved. The result you see is always your own range plus a direction — never the other person's range, and never a numeric distance between you two, even though the underlying values exist on the server to compute the comparison.
In expectation check, the server stores the range endpoints each side submits — not a single exact salary point — because computing overlap needs both ends of a range. What each side sees back is asymmetric on purpose: the responder gets a match percentage and status; the proposer gets the status and, if there's no overlap, a coarse step distance — never the responder's exact expected range. And the responder never sees the proposer's proposed range through the underlying data, regardless of what the interface shows — that restriction is enforced server-side, based on which role your participant token is bound to, not by hiding a number in the UI.
Why this shape resists leaking a salary
A few mechanics reinforce the rules above. Results only unlock once both people have submitted, so no one can see a partial result and adjust their own answer. Each role can submit exactly once — there's no editing your way toward a desired outcome after seeing what happens. And requests are rate-limited, so a script can't cheaply probe a room by trying many values.
None of this is a promise that BallPark is uncrackable — two people who both run multiple comparisons against each other could, in principle, learn more than a single comparison reveals. It's why we keep the surface area small: fewer features, fewer chances for a clever combination of comparisons to reconstruct an exact number.
For the full list of what's collected, retained, and never shared, see our Privacy page and FAQ.