Accept or Decline Wheel

2 segments, one draw

This is one of the site's 2-segment decision wheels. The engine's own range starts lower: a list of 1 entry is a valid wheel, and computeSegments gives it 1 segment from 0° to 360° that can only ever return Accept. The preset list has 2 entries, so computeSegments divides the circle into 2 equal segments of 180° each, in list order: Accept runs from 0° to 180° clockwise from the pointer, with its midpoint at 90°, and Decline runs from 180° to 360° with its midpoint at 270°. Each takes a different color from the fixed 8-color palette, and each wins with probability 50.00%. None of those figures is typed into this page: every angle, percentage, byte count, entry count, error message and link length below is computed at build time by the same engine that runs the wheel above, so the prose cannot drift from the code. The only typed numbers are the scripted input bytes in the worked examples, stated so you can trace them by hand.

The order of operations is the whole point. The moment you press Spin, the engine asks crypto.getRandomValues, the browser's cryptographically secure generator, for random bytes and maps them onto the 2 segments by rejection sampling. Only after the winner exists does the roughly four-second, ease-out rotation begin — a rotation calculated to decelerate so that the winning segment's midpoint (90° for Accept, 270° for Decline) lands under the pointer. The wheel's resting position, the timing of your click, the deceleration curve, and every previous spin have no influence on the result. If your system asks for reduced motion, the animation is skipped entirely and the identical draw is announced immediately — the clearest demonstration that the spinning was never the deciding part.

Rather check than trust? The guide Is the wheel rigged? How to check walks through verifying these claims on your own screen, step by step. The mechanism itself is written up on the methodology page, and the rest of the walkthroughs live in the guides.

Reading the byte: a scripted spin

The draw on this wheel is small enough to follow by hand. Mapping random bytes onto N segments starts by taking the minimal number of bits whose range covers N; for 2 segments that is 1 bit. The engine masks every other bit of the byte away and reads what is left as the winning index — 0 is Accept, 1 is Decline. Because every value the mask can leave is below 2, nothing is ever rejected on a two-segment wheel: the redraw loop that protects larger wheels from modulo bias has no work to do here. The spins below use a scripted byte source in place of crypto.getRandomValues, so the outcome is reproducible at build time; live spins draw real random bytes.

• Byte 254 (binary 11111110) → Accept; the wheel decelerates onto 90°.
• Byte 255 (binary 11111111) → Decline; the wheel decelerates onto 270°.
• Byte 0 (binary 00000000) → Accept; the wheel decelerates onto 90°.
• Byte 1 (binary 00000001) → Decline; the wheel decelerates onto 270°.

Bytes 254 and 0 differ in every bit but the lowest, and both land on Accept; bytes 255 and 1 likewise both land on Decline. The scripted source counted 4 bytes requested across those 4 spins — one per spin, the build-time evidence that this wheel never redraws. Drive every possible byte value through the same mapping, as the automated tests do, and of the 256 values all 256 are accepted on the first draw: 128 land on Accept and 128 on Decline. That is what "exactly 1/2" means here — not a long-run average that a lucky streak could dent, but an equal split of every input the generator can produce.

Why a third option changes the arithmetic

The Yes or No Wheel offers an optional third segment; this page does not, but the same edit is one line away in the entries box, and it is worth seeing what it does to the draw. With the list Accept, Decline, Ask for a week, computeSegments returns 3 segments of 120° at 33.33% each. Covering 3 outcomes needs 2 bits, and the values those bits can hold now include 1 that is at or beyond 3. When the mask leaves such a value, the engine discards it entirely and draws again — it never takes a remainder, because value % N would fold the surplus onto the low-numbered segments and quietly favor Accept.

Scripted runs make the discard visible. Given the byte 7, the mask leaves a value at or beyond 3, so the engine rejects it and asks for another byte; the tally records 2 bytes for a single pick, and the second byte, 2, is accepted as index 2: Ask for a week. Given the byte 1 instead, the first value is already in range — 1 byte, index 1, Decline. Across all 256 byte values, 192 are accepted first time and each of the 3 outcomes receives exactly 64 of them; the other 64 map to nothing at all. Because the mask keeps acceptance above half, redraws are rare and spins stay instant.

Editing the two labels

The preset is a starting list, not a cage: the entries box under the wheel takes whatever two labels fit the reply you are drafting — "Accept" and "Send regrets", or the names of the two events you were invited to on the same night. Parsing follows the same rules on every wheel, and every count and error message in this section comes from calling parseEntries at build time on the text quoted beside it. One entry per line; a single line containing commas splits on the commas; entries are trimmed and blank lines dropped. Typed on one line, "Accept, Decline" parses to 2 entries, Accept and Decline. Put each option on its own line and commas survive inside them: the 2 lines "Accept, with a plus-one" and "Decline, but send a gift" parse to 2 entries with their commas intact, because the comma rule only fires on single-line input.

Duplicates are a weighting mechanism, not an error. The 3 lines "Accept", "accept", "Decline" parse to 3 entries with the duplicate switch off, and computeSegments builds 3 segments of 120° — 2 of them labelled Accept and accept, the same word in two spellings — so a segment reading Accept in one spelling or the other wins 66.67% of spins and Decline 33.33%. The weighting is visible on the wheel and travels inside any share link, so nobody deciding with you can be surprised by it. Tick Remove duplicate entries and the same text parses to 2 entries, Accept and Decline: duplicates are matched case-insensitively and the first occurrence wins.

The caps are honest. A wheel holds at most 100 entries and each entry at most 80 characters, and the engine refuses rather than trims. Feed it 101 numbered lines and the message reads: "A wheel holds at most 100 entries — this list has 101. Remove some entries; nothing was silently dropped." A single entry of 91 characters — typed on one line with no commas, so nothing splits it and the cap is judged against the whole entry — gets: "Entries are limited to 80 characters — "Accept but only if t…" is too long to fit on a segment."

Why invitations deadlock us

An unanswered invitation is a debt: every day it sits, the eventual "no" gets more awkward and the eventual "yes" less enthusiastic. The deadlock usually is not about the event — it is about obligation pulling one way and energy the other, in a tie that re-runs identically every time you think about it. A random draw breaks the loop mechanically: either you accept the verdict and reply within the minute, or you notice yourself resisting the verdict and reply the other way — also within the minute. Both outcomes beat day four of silence.

A protocol that keeps it honest

Decide the stakes before spinning: is this spin binding, or advisory? Binding suits low-stakes invitations where either answer is fine. Advisory — the gut-check mode — suits everything else, and one spin only; re-spinning until the wheel agrees with you is just deciding with extra steps, and the visible spin history will testify to exactly that.

The page gives that protocol a memory. Every spin is written to the Spin history under the wheel, newest first, with a Clear history button; the history exists only on the page and dies with the tab, as do the spins and results themselves. The list you edit is different: it is saved in your browser's local storage, on your device, so it survives a reload, and Reset list restores the preset and removes the saved copy. Nothing you type is transmitted — the only path a list takes off your machine is a share link you copy yourself — and you can verify that: open your browser's network tab and spin. No request carries your entries.

Where a page's wheel touches a serious use, the page says so directly, and this is that page. A uniform random draw gives Accept and Decline exactly 50.00% each whatever is at stake. That is the right property for a tie between two answers you would sign either way, and exactly the wrong property for a decision that deserves weighing. SpinThatWheel is not a substitute for professional judgment: for an offer of work, or anything whose consequences outlast the evening, the spin's honest role is the advisory one described in the FAQ below, and the decision stays yours.

Several invitations: an eliminator walk-through

This page's wheel has no eliminator toggle — with 2 entries the survivor is settled by a single spin — but the custom wheel on the landing page does, and it is the tool for a stack of invitations of which you can accept only one. Type the invitations as the list, tick eliminator mode, and each spin removes its pick from the wheel; the last entry standing is the one you accept. Every elimination is a fresh uniform draw over the entries still remaining — 1/N on the first spin, 1/(N−1) on the next, and so on — and every entry survives with probability exactly 1/N, so the order you typed them in confers nothing. Elimination states are immutable values in the engine, which is what makes the following run replayable.

Take 4 short entries, Saturday wedding, Book club, Block party, Charity run: 90° each and a 25.00% chance each on the first spin. With the scripted bytes 2, 3, 0, 1 standing in for the browser's generator, the engine produces this sequence:

1. Spin 1: 4 remaining, 25.00% each; 1 byte consumed; Block party eliminated (index 2 of the pre-spin list). Still in: Saturday wedding, Book club, Charity run.
2. Spin 2: 3 remaining, 33.33% each; 2 bytes consumed; Saturday wedding eliminated (index 0 of the pre-spin list). Still in: Book club, Charity run.
3. Spin 3: 2 remaining, 50.00% each; 1 byte consumed; Charity run eliminated (index 1 of the pre-spin list). Still in: Book club.

The survivor is Book club, settled in 3 spins and 4 bytes. Spin 2 consumed 2 bytes because, with 3 remaining, the first byte was rejected — the same discard shown in the three-option example above, happening inside an elimination. On the live page each pick and the final winner are written to the history, the status line under the toggle counts the remaining and eliminated entries, editing the list mid-elimination restarts the elimination on the new list, and once it is finished, unchecking and re-checking eliminator mode runs it again from the full list.

Sharing the wheel with whoever is deciding with you

Copy share link percent-encodes each entry, joins the entries with |, and appends the result to the page address as a #items= fragment. The links and lengths in this section are built by that same code at build time. For the preset the link is https://spinthatwheel.net/accept-decline-wheel/#items=Accept|Decline: 14 characters of payload against a cap of 1800. Entries with commas or spaces encode them — the multi-line example above becomes Accept%2C%20with%20a%20plus-one|Decline%2C%20but%20send%20a%20gift, 66 characters — and decoding runs the same validation as typing the list by hand. Browsers do not include fragments in web requests, so opening a share link rebuilds the wheel locally without sending the list to the hosting server; legacy ?items= links are still accepted. An over-long list gets an honest error rather than a truncated link, and a damaged link is reported as damaged rather than decoded into a garbled wheel. Send the link and both screens show the same 2 segments, but each screen makes its own draws: a share link carries the list, and only the list.

How to read the result, and the common misreadings

The result line names the winner; the history keeps the recent sequence. Everything else on the screen is presentation, and most misreadings come from treating presentation as evidence.

• "It nearly landed on Decline." It could not have. The wheel is rotated so the winner's midpoint — 90° or 270° — sits under the pointer; a near miss is staged deceleration onto a result that was already decided by index.
• "3 Accepts in a row — it must be stuck." Each spin is an independent draw from fresh random bytes; the engine keeps no memory of the last result. The probability of 3 consecutive Accepts is (1/2) to the power 3, which the build computes as 12.50% — uncommon, not impossible, and no more evidence of rigging than the same run of Declines would be.
• "I'll spin again to be sure." The history shows your most recent spins, newest first, so a second spin is a visible decision to overrule the first. The protocol above exists so that the first spin is the one that counts.
• "The segments look equal, so the odds are equal." They are — but for the reverse reason. Probability comes from the draw, not the drawing; the geometry exists for the eyes only. A duplicated entry, as shown above, is the one edit that changes the odds, and it changes the picture to match.
• "The wheel decided, so it is decided." The wheel cannot know your situation. It has answered the question you gave it, at exactly 50.00% each, and nothing more.

If a result or a figure on this page looks wrong to you, that is exactly the report the contact page asks for; the guide Is the wheel rigged? How to check shows what to look at first.

Related wheels

The domestic sibling of this decision lives on the Go or Stay Wheel. For a plainer framing, the Yes or No Wheel adds an optional Maybe — the RSVP button no invitation offers — and the Coin Flip Wheel is the classic form of the same draw. Longer walkthroughs of the mechanism live in the guides.

Frequently asked questions

Advisory by design: for anything consequential, treat the spin as a gut check, not a verdict. The draw runs locally in your browser — mechanics on the methodology page.