Export Apple Health to JSON in 2026: Where Each Route Sends Your File
Three routes get your Apple Health data into JSON today. All three hand you a file. Only two keep the raw export on hardware you own, and that difference outlasts any formatting argument.
AI-assisted, human reviewed. How we use AI
Quick answer
To export Apple Health as JSON in 2026 you pick one of three routes: a browser converter, the free built-in export from the Health app that you convert on your own Mac, or an on-device app that writes the JSON itself. The browser converter uploads your file to a server you do not control. The other two never do. Pick on that basis first, then worry about the shape of the JSON.
Why this query is a mess right now
Search export apple health data json 2026 and you get a wall of browser tools that all promise the same thing in the same words. In our own sweep on 25 October 2026 the results included healthsave.app, vitalina.app, healthapi.app and healthmd.app, alongside a converter app listing in the store. healthexport.dev did not appear in that set at all, which is why this page exists.
Here is the problem with that whole result page. Every tool on it answers can I get JSON. Not one answers the question that actually decides which tool you should use: where does my file go.
Sourcing note. The tool names above come from our own recorded search sweep on 25 October 2026. We have not audited those services, we are not claiming they do anything wrong, and we cannot tell you what any of them does with an uploaded file. That is exactly the problem. Nobody outside the company can.
The one question to ask any converter
A browser converter works one way. You choose your export.zip, the page uploads it, a server parses it, and you download the JSON. There is no other architecture available to a website. Your file left your device the moment the upload bar moved.
That is not automatically bad. It is just a decision you should make on purpose. Before you upload a full health history to anything, get four answers in writing:
- Is the uploaded file deleted immediately, and is that deletion verifiable?
- Does the file touch backups, logs or a content delivery network on the way through?
- Is the transfer encrypted in transit, and is the parsed result encrypted at rest?
- Does the page sell, share or train on anything derived from your upload?
If a page cannot answer those four, treat it as a one-off convenience for data you would not mind losing, not as the way you move your health history around.
Route 1: the browser converter
Where your file goes: to their server, then back to you as JSON.
It is the fastest route and it needs nothing installed. Drop the archive in, get a file out. For a one-time look at a single metric it is genuinely fine.
The limits show up later. You have to re-export from the Health app and re-upload every time you want current numbers. The output is whatever column set that tool decided on. And the upload step is permanent by design, because that is how the tool is built.
Route 2: the free built-in route, converted on your own Mac
Where your file goes: nowhere. It stays on your phone, then on your Mac.
Apple ships an export. Open the Health app on your iPhone, tap your profile picture, choose Export All Health Data, and save the export.zip it produces. AirDrop it to a Mac and unzip it.
Inside you get export.xml, plus folders for electrocardiograms and workout route files. export.xml is one very large XML document. Every sample is a Record element with a type, a start and end date, a value and a unit. That is all the structure you need.
Convert it locally with the Python standard library. Nothing is uploaded, so there is no policy to read:
python3 - <<'PY'
import json, collections
import xml.etree.ElementTree as ET
root = ET.parse('apple_health_export/export.xml').getroot()
by_type = collections.defaultdict(list)
for rec in root.iter('Record'):
by_type[rec.get('type')].append({
"start": rec.get('startDate'),
"end": rec.get('endDate'),
"value": rec.get('value'),
"unit": rec.get('unit'),
})
with open('health.json', 'w') as fh:
json.dump(by_type, fh, indent=2)
print({k: len(v) for k, v in by_type.items()})
PYThat prints a count per metric type and writes health.json. If your history is big, swap ET.parse for ET.iterparse and clear each element after you read it, otherwise you are holding the whole document in memory at once.
The honest downsides: it is manual, it is a snapshot the moment it lands, and it will be stale by next week. For a single archive you want to keep, this is the right answer and it costs nothing.
Route 3: an on-device app that writes the JSON itself
Where your file goes: the destination you choose, and nothing else.
This is the route MetricBridge takes. You connect Apple Health read-only, and the app writes 190 Apple Health and Apple Watch metrics as clean local JSON to iCloud Drive, a synced folder, your local network or a webhook. There is no account and nothing on our servers, so there is no upload step to reason about.
The same data answers questions on the phone itself. Ask something like how did my resting heart rate trend over the last 30 days and the answer is computed on the device, with a card underneath showing the exact samples and date range behind the number. A reading that sits outside your own recent range is described as a deviation from your personal baseline, not as a verdict.
Where this route earns its keep is recurrence. An agent does not want a file you exported in June. The open-source MCP server is zero-dependency Node with 16 read-only tools, and it reads the same local folder the app writes to, so the data an agent sees is the data that just synced.
The routing table
| Route | Where the file goes | Freshness | Setup |
|---|---|---|---|
| Browser converter | Uploaded to their server | Manual re-export each time | None |
| Health app export, converted on your Mac | Stays on your devices | Manual re-export each time | A short local script |
| On-device app export | The destination you pick | Kept current automatically | Install an app |
Which one you actually want
If you need one snapshot today and you have read the policy, upload it to a converter and move on. That is a reasonable trade.
If the data is going to sit on your own machine and you enjoy a terminal, the built-in export plus thirty lines of Python is the cheapest honest answer.
If the data is feeding an AI agent, or you want it current without thinking about it, you want the file written on the device. Any route that needs a manual re-export will be stale exactly when the question matters.
JSON that never leaves your iPhone
190 metrics as clean local JSON, plus the zero-dependency MCP server with 16 read-only tools. One-time $24.99 unlock, no subscription. No account, nothing on our servers.
Frequently asked
How do I export Apple Health data to JSON?
You have three routes. A browser converter takes your export.zip upload and returns JSON. The free built-in route gives you export.xml from the Health app, which you convert locally on a Mac. An on-device app like MetricBridge writes JSON for 190 metrics straight to a destination you choose, such as iCloud Drive, a folder, your local network or a webhook.
Does a browser converter upload my Apple Health data?
Yes. A browser-based converter has no other way to work. Your export.zip leaves your phone or laptop, arrives at a server you do not control, is parsed there, and the JSON comes back. What happens to the uploaded copy afterwards depends on that operator's policy and retention, and we have not audited any of those tools. If that matters to you, use a route where the file never leaves your own machine.
What is inside Apple Health's export.zip?
The Health app writes one archive containing export.xml, plus separate folders for electrocardiograms and workout route files. export.xml holds every recorded sample as an XML Record element with a type, a start and end date, a value and a unit. It is one very large file, which is why editors and chat windows struggle with it.
Can I convert export.xml to JSON without uploading it anywhere?
Yes. Unzip the archive on your own Mac and parse export.xml with a short Python script using the standard library. Nothing leaves the machine. The tradeoff is that it is manual, it is a snapshot rather than a live feed, and large histories need a streaming parser rather than loading the whole file into memory.
Which route should I use for an AI agent?
An agent needs data that is current and machine-readable, not a file you exported last month. MetricBridge exports 190 Apple Health and Apple Watch metrics as clean local JSON and ships a zero-dependency MCP server with 16 read-only tools, so an agent reads the same local folder your export writes to. No accounts, no cloud AI in the path.