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 argument about JSON shape.

The question the converter pages skip

Search how to turn Apple Health into JSON and you get a wall of browser tools that promise the same thing in the same words. Every one of them answers "can I get JSON". None answers the question that actually decides which tool you should use: where does my file go.

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 fine. The limits show up later. You re-export and re-upload every time you want current numbers, 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.

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.

Convert it locally with the Python standard library:

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)

That 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 hold 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, it 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.

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. No account, nothing on a server. The same data answers questions on the phone itself, computed on device, with a card underneath showing the exact samples behind the number.

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

Four questions before you upload a full health history anywhere

Any converter that parses on its own server should answer these in writing first:

1. Is the uploaded file deleted immediately, and is that deletion verifiable?
2. Does the file touch backups, logs or a CDN on the way through?
3. Is the transfer encrypted in transit, and is the result encrypted at rest?
4. 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.

The full write-up, with the routing table and the local recipe in one place, is on the site: https://dub.sh/htX0Cgl