Apple Health Export to CSV

How this works

Apple Health exports as a single XML file called export.xml. Every measurement is a Record element with a type identifier, a start and end time, a value, a unit, and the device that wrote it. Workouts are separate Workout elements. The file is flat, one element per line, which is why it can be streamed instead of loaded into memory all at once.

The page makes two passes. The first pass reads the file line by line, counts records per type, and tracks the earliest and latest start date. That produces the metric list and the default date range. The second pass runs only after you click Build CSV, and it extracts only records whose type matches your choice and whose start date falls inside the range. Nothing is stored between passes.

This is the part that general converters skip. A whole-export CSV mixes steps, heart rate, sleep, and hundreds of other types into one table, which is unusable for a chart or a pivot table. Choosing one metric first produces a table with one consistent unit and one value column. The date range keeps the download small enough to open in Excel.

Sleep is handled differently from the quantity types. Apple stores it as a category, so the value is a label such as HKCategoryValueSleepAnalysisAsleepCore or HKCategoryValueSleepAnalysisInBed. The useful number is the duration, calculated from the start and end timestamps. Daily aggregation is disabled for sleep because the stages are already intervals, and summing them would double count.

Common metrics and what the CSV contains

The metric list is built from your file, so a type that is not in the table above still appears with its raw identifier and a count. Units are whatever Apple wrote in each record, usually the unit set in the Health app, so a US phone may write miles and pounds where a UK phone writes kilometres and stone.

When you would use this

You want to chart your sleep stages over the last six months and the full export is too large to open. Choosing Sleep analysis and a date range produces one table of intervals that a spreadsheet can chart directly.

You are preparing a heart rate or HRV table for a coach or a clinician. They need one metric with consistent dates and units, not a mixed export with every category Apple tracks.

You want steps per day for a year. Raw step samples are dozens per day and meaningless in a chart. Daily total collapses them into 365 rows with one number each.

You are building a personal dataset for a script and need to know which type identifiers your phone actually writes. The scan shows every type found with a count before you export anything.

You switched phones and want to compare a metric across two exports. Run each file separately with the same metric and date range, then join the two CSVs on the date column.

What this does and does not handle

It handles:

• Streaming a large export.xml without loading the whole DOM.
• Discovery of every record type in the file, with counts and date bounds.
• Filtering by metric and by start-date range.
• Raw rows, daily total, and daily average.
• Duration in seconds for interval records such as sleep.
• Workout elements with activity type, duration, energy, and distance.
• UTF-8 CSV with a byte order mark for Excel.

It does not handle:

• Parsing the ZIP that Apple wraps around the XML. Unzip it first, then load export.xml.
• Workout route points, splits, or child events. Only the attributes on the Workout element are exported.
• Correlation records such as blood pressure pairs. They appear as their own type but their child records are not merged.
• Clinical records from Health Records. Those use a different element and are not read.
• Unit conversion. The value and unit are exported as Apple wrote them.
• Deduplication across sources. If an iPhone and a watch both recorded steps, both records appear. Daily total sums both, which double counts overlapping sources.
• Files that are not XML. The page checks the first line and reports a clear error.