Before You Share a Poker Hand History: Minimize PHH

A portable poker hand history is not automatically a private one. Before sharing PHH, keep only the fields needed for the intended review, replace or remove player names, delete optional context and free-text commentary, and inspect what remains. Exact cards, stacks, and actions can still identify a hand when somebody can match them to another record. A minimized file is not anonymous.

This guide’s workbench checks one TOML-derived Poker Hand History file against a conservative profile pinned to PHH v0.0.2. It then builds a new, smaller document locally in your browser. It is an editorial tool—not the official PHH validator, a legal privacy assessment, a general converter, or a new GTO Gecko import format. The published example is synthetic.

Disclosure: GTO Solutions AS publishes this site and GTO Gecko. The PHH format, PokerKit, Open Hand History, and NIST guidance cited here are external source materials. GTO Gecko does not currently support PHH import or export.

Why a PHH File Needs a Sharing Check

The PHH specification defines a human-readable, machine-parsable way to record poker. Its required state fields describe the variant, relevant forced bets and limits, starting stacks, and an ordered action list. The current v0.0.2 profile covers 11 variants, including no-limit hold’em, pot-limit Omaha, stud, razz, and draw games.

The same specification permits rich optional context: player and author names, event URL, venue and address, city, time zone, hand and table numbers, physical seats, winnings, currency, and time banks. An action string can include commentary; a PHH file can also contain underscore-prefixed custom fields. Those details can be useful in a private archive. Most are unnecessary when the recipient only needs to study a decision.

Removing commentary is a privacy choice with an information cost. Notes may be the only place a recorder captured an exposed card, interruption, live read, or metagame condition. The minimized copy preserves normalized PHH action tokens, not commentary-only decision context. For the study process after choosing a hand, the poker practice guide explains how to write reasoning before checking the result and turn a finding into a drill.

The working rule is simple: share the smallest record that serves the stated purpose. Parse before transforming; do not use a line-based comment stripper, because a hash inside a TOML string is data. Keep strategically meaningful values exact. If that exact pattern is itself sensitive, do not publish the hand—or replace it with a clearly labeled synthetic example.

PHH is not the only interoperability project. Open Hand History is a separate JSON specification, published as version 1.4.7 on March 4, 2024, whose guiding principles call for replayability without loss from the user’s perspective. This version of the workbench accepts neither OHH nor native poker-room text and performs no conversion between them.

The Public-Share-Minimum Field Policy

The complete field matrix (CSV) lists every v0.0.2 field and its default disposition. The machine-readable policy (JSON) records the same rules, guarantees, and non-guarantees.

What the Local Checker Actually Tests

Your pasted text is processed in memory inside a sandboxed frame that has no same-origin permission and whose content policy blocks network connections. Parent-page analytics cannot inspect the editor’s opaque-origin document. The workbench does not place the hand in a URL, browser storage, analytics event, or upload request. Loading this page, using browser extensions, copying into a clipboard manager, downloading a file, and sharing through another service are separate data flows. “Browser-local transform” is deliberately not a blanket security promise.

1. Browser parser boundary. The pinned smol-toml 1.8.0 dependency advertises support for TOML 1.1.0 but documents exceptions such as accepting certain invalid dates, so this is not a strict TOML conformance check. The workbench rejects syntax errors reported by that parser, requires the PHH time field to be a valid local-time value, rejects unsafe integers, and rejects decimal literals that would change value when serialized through the browser number type. Safe integral floats and integers both become JavaScript numbers, so the profile treats 8.0 like 8 in integer-valued optional fields.
2. Pinned PHH structure. It recognizes the 11 v0.0.2 variants, requires the applicable state fields, checks player-aligned array lengths and numeric types, rejects incompatible betting-structure fields, and fails closed on unknown standard-looking fields.
3. Action-token shape. It checks indexed actors, canonical positive raise amounts, card-token syntax, short-deck rank exclusions, and the documented action forms. It removes only a standalone action-commentary delimiter, then canonicalizes whitespace.
4. Before/after invariant. It compares the normalized PHH state fields and action tokens, serializes and reparses the output, runs the structural profile again, and requires a byte-stable second transformation. Commentary is deliberately outside the invariant.

That is a structural gate, not a poker engine. It does not check duplicate cards, full deal order, turn order, stack sufficiency, legal raise bounds, pot settlement, hand ranks, or future PHH versions. A clean workbench result means “accepted by this published profile,” not “officially valid poker hand.” Input is limited to one document and 100,000 characters.

A Synthetic Before-and-After Test

The public fixture is a three-player no-limit hold’em hand with 18 actions. The rich input deliberately includes three synthetic names, an event and URL, venue and address, local time, hand and table identifiers, seats, result fields, currency, two custom fields, and private-looking commentary.

Under the default profile, the transform removes 29 top-level fields, including two custom fields; strips commentary from four action entries; replaces the three names with Player 1 through Player 3; and omits the default ante_trimming_status = false. It retains the no-limit variant, antes, blinds, minimum bet, starting stacks, and ordered action core. The JavaScript comparison reports that normalized strategic payload as unchanged.

Official PHH tooling documentation lists PokerKit, the Python library used for the separate replay check. The browser workbench does not send visitor input to PokerKit. PHH and PokerKit also share project provenance, so this is a separate implementation path—not independent institutional evidence.

PokerKit 0.7.5 emitted one warning for the rich source: it treated time_zone_abbreviation as unexpected even though the field appears in the tagged v0.0.2 specification. The minimized copy removes that field. Reporting the warning separately is more accurate than collapsing syntax, structural acceptance, and replay into one “validated” badge.

Download and Reproduce the Evidence

• Synthetic rich PHH input and default minimized output
• Field-removal report and SHA-256 hashes (JSON)
• Standard-library Python verifier
• Pinned PokerKit replay verifier and exact dependency file
• Commands, environment, files, and primary-source ledger

Run the standard-library verifier first; it checks field allowlisting, synthetic privacy sentinels, the strategic payload, and file hashes without importing the browser implementation. The optional replay path installs exactly pokerkit==0.7.5 and compares public game-state snapshots. These checks support the claims about this fixture; they do not establish anonymity or universal conformance.

The Risk That Remains After Names Disappear

NIST SP 800-188 concerns government datasets, not poker files and not a legal safe harbor. Its useful general lesson is that removing direct identifiers does not eliminate re-identification risk: disclosure also depends on quasi-identifiers, high-dimensional patterns, other available records, and the release context.

For a poker hand, the remaining fingerprint can be unusually specific. A stream, forum post, room export, group chat, or opponent database may contain the same board, stack distribution, and betting sequence. Player 2 remains linked to that indexed player’s actions inside the file. The attachment name, screenshot, or surrounding message may reveal the date and game that the document no longer states.

• Could the exact cards, amounts, and action sequence be matched to another source?
• Does the filename or surrounding message restore the context you removed?
• Does the recipient really need exact accounting data or shown cards?
• Do consent, room rules, platform terms, or research policy permit the disclosure?

Pseudonymization is useful field hygiene. It is not unlinkability, consent, legal compliance, or an anonymity guarantee. Local processing reduces transport and service-retention exposure; it does not make a file safe to publish.

Where GTO Gecko Fits—and Where It Does Not

GTO Gecko is a separate off-table study workflow. As checked on September 3, 2026, its web importer accepts supported plain-text no-limit hold’em histories from GGPoker, PokerStars, and CoinPoker; WPT Global is routed through a third-party converter to PokerStars text. Supported hands can be stepped through on a replayer timeline and, where a situation can be matched, reviewed against available solver data.

GTO Gecko does not currently import or export PHH .phh or .phhs files. If a hand you are entitled to use is already in a supported GTO Gecko import format, review it there. Use this workbench for a different job: checking and minimizing a portable PHH document before a justified share. The workflows are adjacent, not integrated.

PHH Privacy FAQ

Is a minimized PHH file anonymous?

No. Names and context can disappear while cards, stacks, amounts, and actions remain linkable to another record.

Does a clean workbench result prove full PHH compliance?

No. It passed this pinned structural profile. Full replay and poker-rule validity are separate checks, and the profile does not predict future PHH versions.

Should I always remove finishing stacks and winnings?

Remove them by default for decision study. Keep them only for a stated accounting or reconciliation need, and accept the added linkage risk.

Can GTO Gecko open the minimized file?

Not at present. GTO Gecko’s supported text importer and PHH are separate formats.

Sources and Methodology

Sources and current product behavior were checked on September 3, 2026.

• University of Toronto Computer Poker Research Group, PHH repository at tag v0.0.2, plus the stable specification and optional-field reference. Used for the field matrix, types, action notation, and default ante-trimming behavior.
• Juho Kim, “Recording and Describing Poker Hands”, revised August 29, 2024. The paper reports a 10,088-hand evaluation corpus covering 11 variants.
• PHH project, tooling guide; University of Toronto CPRG, PokerKit repository; and PokerKit paper. Used for the pinned fixture replay path.
• National Institute of Standards and Technology, SP 800-188: De-Identifying Government Datasets. Used only to frame linkage and release-context risk.
• Open Hand History specification, version history, and guiding principles. Used to avoid presenting PHH as the only hand-history standard and to report OHH’s stated replayability goal with its public version date.
• TOML 1.1.0 specification and smol-toml 1.8.0 source and README. Used to pin and disclose the browser parser’s advertised dialect and documented date-validation limitation.
• GTO Gecko, live hand-history importer. Used to verify the product boundary and supported input wording.
• GTO Gecko, PHH privacy evidence README, machine-readable policy, and fixture report. Generated and accessed September 3, 2026.