HY3 file format

HY3 is the file format Hy-Tek’s Meet Manager and Team Manager use to move swimming entries and results between themselves and to hand them to other software. Hy-Tek has never published a specification for it. What is known about it was worked out by swimming volunteers between 2010 and 2013 and has been public ever since.

Form¶

An HY3 file is plain text, and every line is exactly 130 characters: 128 of content followed by a two-character checksum. The first two characters identify the record type, and the fields that follow sit at fixed column positions, so the file opens readably in any text editor.

The record types in a results file are consistent. A check of two real exports, one written in 2010 and one in 2025, found the codes below, with E1 and E2 appearing in exactly matching numbers, as did F1, F2 and F3, so entries and their results are written in pairs. Part of the vocabulary is borrowed from SDIF, the published standard, and part is Hy-Tek’s own.¹²

Code	Carries
A1	One per file: what kind of export it is, the software and version that wrote it, the date, and who the copy is licensed to
B1, B2	The meet: name, facility, start, end and age-up dates, course, elevation
C1	A team: code, full and short names, and its regional body
D1	A swimmer: names, registration identifier, date of birth, age
E1, E2	An individual entry and its result
F1, F2, F3	A relay entry, its result, and the swimmers who made up the team
G1	Splits
H1	A disqualification

Two records read¶

Below are two well-formed records. The swimmer and the club are invented, but the lines are real in every other respect: each is 130 characters and carries the checksum the algorithm computes, so a reader can verify them.

A team record, C1:

C1RVRS Riverside Swim Club           Riverside       NE                                                                         75

Columns	Field	Value
0–1	Record code	C1
2–6	Team code	RVRS
7–36	Full name	Riverside Swim Club
37–52	Short name	Riverside
53–54	Regional body	NE
128–129	Checksum	75

A swimmer record, D1:

D1F    7Wren                Marguerite          Daisy               A082692MARAWREN    708261992 33                             35

Columns	Field	Value
2	Sex	F
3–7	Swimmer number	7
8–27	Last name	Wren
28–47	First name	Marguerite
48–67	Preferred name	Daisy
68	Middle initial	A
69–82	Registration identifier	082692MARAWREN
83–87	Team’s own swimmer number	7
88–95	Date of birth	08261992
96–98	Age	33
128–129	Checksum	35

Two generations of registration identifier turn up in this field, and which one a file carries dates it. The older is USA Swimming’s legacy number, built rather than assigned: six digits of date of birth, three letters of the given name, the middle initial, and four letters of the surname, with an asterisk padding any part too short to fill its run.³ In the 2010 sample file that construction accounts for 44 of the 46 swimmer records. The newer is opaque, a fourteen-character hexadecimal string that encodes nothing a reader can decompose; it fills 359 of the 437 swimmer records in the 2025 sample, where the built form appears not once and a further 78 records leave the field empty altogether.⁴

The privacy consequence belongs to the older form and is narrowing rather than settled. Where a file uses the built identifier, an HY3 carries more about a swimmer than the published results do: a results PDF gives a name and a time, while the file behind it gives a date of birth, and at an age-group meet most of those entrants are children. Meet hosts pass these files around by email as a matter of routine. The opaque identifier removes the derivation but not the date of birth, which is still present in its own field on most records.

The checksum on that record¶

Taking the team record above, the 128 content characters weight out to 9,494. Dividing by 21 and discarding the remainder gives 452; adding 205 gives 657; and the last two digits written backwards give 75, which is what sits in columns 128 and 129.

Where it sits¶

Hy-Tek writes HY3 alongside its older CL2, not in place of it. Every results export is a zip carrying both, and the company pins the changeover to a program version instead of a year: Team Manager releases before 4.0G read the CL2, and 4.0G and later read the HY3, which carries what the older format cannot, including results by division, semi-finals and swim-offs.⁵ The event list is paired the same way, as HYV and the newer EV3, on the same 4.0G boundary.⁶

The format is not confined to the desktop programs either. An entry file built by Active’s current web product is a zip containing an HY3, so this is the live interchange and not a survival.⁷

The checksum¶

The two characters at the end of each line are a check digit, and Hy-Tek enforces them: a line whose checksum is wrong will not import.¹ For most of the format’s life that made HY3 effectively write-protected against outsiders, who could read a file perfectly well but could not produce one the company’s software would take.

That changed on 28 October 2010, when a poster signing as jwh published both the HY3 and the CL2 algorithms to the Usenet group rec.sport.swimming.⁸ The HY3 calculation takes the 128 content characters, sums their character codes while counting those in alternating positions twice, divides by 21 and discards the remainder, adds 205, and writes the last two digits of the result backwards, ones digit first.

The description holds. Implemented from that post and run over the two exports mentioned above, it reproduces the checksum on all 4,617 lines, with none failing, so the calculation has been unchanged across fifteen years and two generations of Meet Manager.

It is a weak check. Dividing by 21 and keeping two digits discards most of the information in the sum, so many different lines produce the same value. It will catch a corrupted transfer and little else.

Two details trip people up. The original post counts columns from one and so describes the weighting the opposite way round from every later implementation, which counts from zero; and it gives the content as 129 characters where 128 is what works.⁸

Who worked it out¶

The format was documented by a handful of volunteers in a burst between 2010 and 2013. Mike Walsh, writing a swim-team plugin for WordPress, put the problem publicly in mid-2010 and started a Google group that September to pool what people knew. Joe Hance published the checksums a month later. Troy DeLano ported the calculation, in PHP as far as the surviving attribution goes, then produced a set of record-layout diagrams in 2012 and a consolidated format document in 2013; Walsh wrote the one covering relay records.⁸⁹

That documentation nearly disappeared. The link it had been shared from stopped working, and when someone asked for it again in 2021 Walsh could not find his own copy. It survives because the PDFs were later placed in a public code repository, where their internal metadata still records who wrote them and when.⁹

Reading and writing¶

The best-known libraries read HY3 and stop there. One Python parser declines to validate checksums at all, raising an error that says the feature is not implemented; a second Python project and an R package also read only.²⁴¹⁰

Writing is possible and has been done. Walsh’s plugin exported rosters and meet entries that Hy-Tek’s Team Manager imported, and a TypeScript library now computes checksums as part of building a file.¹¹¹² The path was not smooth: in 2012 Walsh reported that Team Manager accepted his files while Meet Manager refused them, which took further work on records the meet program required and on making the meet dates agree.¹³

So the common belief that Hy-Tek files cannot be generated outside Hy-Tek is wrong, though it is easy to see where it comes from: the three best-known tools are all read-only.

Gaps¶

The format is not fully known even now. One record type is named in the community documentation with no field layout ever published; another appears in a parser’s source and in no written description at all. The individual result record, which carries the times in a results file, has no field table in the main community document, so everything known about it comes from reading code.¹²

Offsets also disagree between implementations, with real consequences: one parser carries a note about having previously read a team’s regional code from the wrong columns, corrupting about a fifth of the values before the error was found.²

Conversion¶

Hy-Tek supplies one official way out, and it does not apply to this format. Meet Manager will convert the CL2 half of an export to SDIF, writing an .sd3 file that any program reading the published standard can take.¹⁴ Nothing documents an equivalent conversion from HY3.

See also¶

• CL2: the older Hy-Tek format shipped in the same export
• HYV and EV3: the event-list exports, shipped as a pair
• SDIF: the published standard, and the format Hy-Tek will convert to
• swimlib: a current library that reads and writes this format
• Meet Manager and Team Manager: the programs that write it
• Software: the software reference

References¶

Footnotes¶

1. Troy DeLano and Mike Walsh, Hy-Tek file format documents (2012–2013; preserved in the hyparse repository after the original link lapsed). ↩ ↩² ↩³

2. SwimComm, hytek-parser (Python reader; record codes, value tables, and the unimplemented checksum validation). ↩ ↩² ↩³ ↩⁴

3. USA Swimming, Swimming Data Interchange Format version 3 (28 April 1998), USSNUM field construction. ↩

4. jgolliher, hyparse (Python reader, and the source of the sample exports examined here). ↩ ↩²

5. HY-TEK, Export results for TEAM MANAGER or SWIMS (Meet Manager 8 user guide; the CL2 and HY3 pair and the Team Manager 4.0G cutover). ↩

6. HY-TEK, Export events for TEAM MANAGER (Meet Manager 8 user guide; HYV and EV3 paired, and what EV3 adds). ↩

7. ACTIVE, Swim Manager: creating a meet entry file (the entry file is a zip containing an HY3). ↩

8. jwh, HY-TEK CL2 and HY3 checksum algorithms, rec.sport.swimming, 28 October 2010. ↩ ↩² ↩³

9. hyparse, resources directory (the recovered format PDFs, with their authorship metadata). ↩ ↩²

10. SwimmeR, hy3_parse (R package reading HY3 results). ↩

11. Michael Walsh, wp-SwimTeam (PHP; exports rosters and meet entries as HY3, and implements the checksum). ↩

12. dmanusrex, swimlib (TypeScript; reads and writes HY3, created September 2026). ↩

13. sdif-forum (the Google group founded in 2010 to pool format knowledge). ↩

14. HY-TEK, Convert a Hy-Tek Export CL2 File to SDIF (Meet Manager 8 user guide). ↩