Drop the Health app’s export and download one CSV for each metric you select.
Your health data never leaves this browser tab
An Apple Health export.xml to CSV conversion starts with the file the Health app already created.
Drop
export.xml, or the
export.zip
that contains it, onto the tool above. The scan lists what is in the file, with a count and a date
range for each metric. Nothing is uploaded.
You then choose which of those metrics to keep. One selected metric downloads that CSV. Several
download
apple-health-export.zip, with one
CSV inside for each metric. The page does not build a single joined spreadsheet. Each metric stays
in its own file, named from the HealthKit type.
On a current iPhone, the export starts in the Health app.
export.xml inside it.
Older iOS versions used a similar export from the Health profile. That older screen is not the path to follow on a current phone.
The zip is large because it holds years of samples. You do not need to unzip it first. If you already
unpacked it, the file to drop is
export.xml, not
export_cda.xml.
The health file is handled only in this tab.
The same boundary is described on the privacy page.
The parser is streaming SAX (saxes)
in a Web Worker. The file is read in two passes, and the rows are not kept. The first pass counts
each metric and its dates. The second pass writes CSV text and flushes it as the read continues,
instead of holding the whole table in memory.
Desktop Chromium can stream the download through the save picker, so the bytes go to the file you pick. Other browsers stream the result into temporary origin storage and then save that file. iPhone and iPad hand the file to the share sheet. They can still run out of memory while reading the export, before any CSV exists. A few metrics at a time, or desktop Chrome, is the fallback when a phone stops. This page does not claim that every phone can convert a multi-gigabyte export.
Every Record with a
type is converted, both quantity
and category samples. Nested records inside a correlation, including blood pressure, become their
own types rather than one joined table. Systolic and diastolic samples show up as two metrics. All
workouts become
workouts.csv, one row per workout.
Activity summaries become
activity-summaries.csv. Unknown
newer record types still export. The display name is derived from the identifier when this site
does not already have a label for it.
Each CSV starts with a
type,<HealthKit identifier>
line, then the column header.
Record columns:
start, end, value, unit, source, sourceVersion, device, creationDate.
Workout columns:
activityType, start, end, duration, durationUnit, totalDistance, totalDistanceUnit,
totalEnergyBurned, totalEnergyBurnedUnit, source, device.
Activity summary columns:
date, activeEnergyBurned, activeEnergyBurnedGoal, activeEnergyBurnedUnit, appleExerciseTime,
appleExerciseTimeGoal, appleStandHours, appleStandHoursGoal.
One selected metric downloads that CSV. Several download
apple-health-export.zip. The date
filter uses the YYYY-MM-DD prefix
Apple wrote, not the browser’s timezone. A sample taken late in the evening stays on the calendar
day stored in the file.
Profile (Me), export date, metadata
entries, per-beat heart-rate samples, workout events, workout statistics, workout routes, clinical
records, audiograms, and vision prescriptions are omitted. A heart-rate variability record keeps
the summary value on the record. The individual beats nested under it are not expanded into rows.
Inside a zip,
export_cda.xml, route GPX files,
and ECG files are not converted. The tool reads the
export.xml entry only.
The error state is titled “Something went wrong”, and the line under it is the message the parser
or the file check produced. The usual mistakes are dropping
export_cda.xml instead of
export.xml, dropping a zip that is
not Apple’s Health export, or a file that contains no records, workouts, or activity summaries.
A zip with no
export.xml entry says: “No
export.xml found in the zip. Select the export.zip that the Health app produced.” A file that
parses but has none of those elements does not get a second, invented message. The scan finishes
and the list is empty. Some iOS versions ship a doctype that does not match the document. The
converter strips that doctype before parsing, which is why a file that other XML tools reject can
still scan here.