- google timeline visualizer supports multiple Google Timeline JSON export structures.
- Records files usually contain raw E7 integer coordinates and detailed location pings.
- Semantic files organize visits, activities, addresses, and timeline segments.
- Phone exports may use nested paths, timestamps, and semantic segment objects.
- Privacy first processing keeps source files in the browser during visualization.
google timeline visualizer Coordinate Formats Explained
The google timeline visualizer coordinate formats workflow starts by identifying how Google packaged your location history. Older exports commonly place raw GPS records in a large JSON file, while newer mobile exports use nested timeline objects, semantic segments, and ISO-style timestamps. A visualizer must recognize these structures before it can draw routes, place visits, or movement patterns.
The most useful approach is to treat each export as a different schema rather than assuming every file uses the same coordinate notation. Uploading multiple compatible JSON files can help combine raw points with semantic details, but the files should be inspected first so duplicate records and incomplete migrations do not create confusing paths.
Video Highlights:
- How local tools translate fragmented Google Timeline exports.
- Why E7 integers require conversion before mapping.
- How route rendering handles sparse points and long-distance travel.
- Why browser-based processing can reduce unnecessary data exposure.
| Format family | Typical contents | Best use |
|---|---|---|
| Records JSON | Raw GPS pings, timestamps, E7 coordinates | Detailed point-level route review |
| Semantic history | Places, activities, addresses, movement segments | Visit and activity analysis |
| Phone timeline export | Nested timeline paths and semantic segments | Recent mobile history visualization |
| Supporting metadata | Settings, edits, export details | Context and timeline corrections |
Raw Point Data
Best for inspecting individual pings, coordinate precision, and GPS noise. It may be the largest file in the export.
Semantic History
Best for understanding where you stayed, which activities were detected, and how Google grouped movement.
Phone Export
Best for newer mobile backups that contain nested paths and timeline segments rather than one flat record list.
Do not rename coordinate fields before uploading. The visualizer can detect supported structures more reliably when the original JSON keys remain unchanged.
E7 Coordinates, ISO Timestamps, and Nested Paths
Coordinate representation is the main difference between older and newer Timeline files. Raw records may store latitude and longitude as scaled integers, often called E7 coordinates. In practical terms, the stored number represents a decimal coordinate multiplied by a fixed scale. A parser converts that integer into a usable latitude or longitude before placing the point on a map.
Modern exports may use decimal coordinates inside nested objects, along with timestamps written in a standard ISO format. Other files can contain a timeline path where each point includes its own timestamp or appears inside a semantic segment. These differences affect filtering, route ordering, and activity interpretation.
| Data element | Older-style pattern | Newer-style pattern | Visualization concern |
|---|---|---|---|
| Latitude | Scaled E7 integer | Decimal value in a nested object | Requires schema-aware conversion |
| Longitude | Scaled E7 integer | Decimal value in a nested object | Must remain paired with latitude |
| Timestamp | Legacy numeric or encoded value | ISO-formatted date-time string | Parser must normalize ordering |
| Route path | Flat record array | Nested path or semantic segment | Multiple traversal levels may exist |
| Activity | Limited or inferred metadata | Walking, driving, cycling, transit labels | Depends on semantic export coverage |
How E7 Conversion Works
An E7 value is not a separate coordinate system. It is a storage format designed to preserve decimal precision using an integer. For example, a parser may convert a stored value into a decimal by applying the format’s scale before mapping it. The exact conversion should be handled by the visualizer rather than manually editing the source file.
Manual changes are risky because a single misplaced decimal can move a point by a very large distance. They can also break JSON syntax or disconnect a coordinate from its timestamp. Keep an untouched backup and use a local parser or the browser visualizer to perform normalization.
Why Timestamp Normalization Matters
A route is only meaningful when points appear in chronological order. Export files may use different timestamp conventions, and semantic segments may contain time ranges rather than one timestamp per point. A good tool converts these values into a common internal representation, then sorts or groups them for calendar and day-level views.
| Normalization task | Why it matters | Recommended handling |
|---|---|---|
| Decode coordinate scale | Places raw integers on the correct map position | Let the parser handle E7 conversion |
| Standardize timestamps | Prevents routes from appearing out of order | Use the tool’s automatic date parsing |
| Join latitude and longitude | Avoids invalid or displaced points | Keep paired fields together |
| Read nested arrays | Finds paths inside semantic segments | Upload the original structure |
| Remove duplicates | Reduces repeated points and visual clutter | Compare timestamps and coordinates |
Editing raw numbers directly can create invalid JSON or move a point dramatically. Preserve the original export and test a copy whenever repair is necessary.
Step-by-Step File Preparation
Preparing a Google Timeline export is easier when you separate backup, inspection, upload, and validation. The goal is not to rewrite the source file. The goal is to give the visualizer enough original information to detect the coordinate format and reconstruct the timeline.
Create an Untouched Backup
Keep the downloaded JSON files in a separate backup folder. Use a second copy for testing, filtering, or combining exports. This protects the original record if a browser session fails or a file is accidentally changed.
Identify the Export Family
Check whether the folder contains a large records file, monthly semantic files, a phone timeline export, or supporting settings and edit files. Do not assume that the newest-looking file contains every historical point.
Upload Original JSON Files
Drop one or more supported JSON files into the visualizer. Multiple files can combine data from different export methods, but overlapping exports may produce duplicate visits or repeated paths.
Apply a Year or Date Filter
Start with a narrow period to confirm that timestamps and coordinates display correctly. Once the route looks accurate, expand the filter to review additional history.
Validate Points and Activities
Open individual points, inspect place visits, and compare activity labels with the route. Investigate extreme jumps before treating them as genuine travel.
The browser-based workflow is designed for retrospective analysis. It can display commutes, trips, visited places, and activity segments, but it is not the same as a live tracker. After the visualization session ends, the temporary processing state is intended to be discarded when the tab is closed.
| Preparation check | Pass condition | If it fails |
|---|---|---|
| File opens as JSON | The structure loads without syntax errors | Re-download or restore the original |
| Coordinates appear | Points display in plausible locations | Check format support and field nesting |
| Timestamps sort correctly | Days and routes follow chronological order | Try a smaller file or different export |
| Activities are visible | Semantic labels appear where available | Use a semantic or phone export |
| Duplicate paths are limited | Overlapping routes are understandable | Upload one export family at a time |
Begin with one small file or one narrow period. Confirm that coordinates, dates, and activities look correct before adding larger exports.
Route Accuracy, GPS Noise, and Travel Gaps
A coordinate parser can be technically correct while the displayed route still looks unusual. GPS data often includes noise caused by weak signals, indoor positioning, multipath reflections, or temporary loss of satellite visibility. A phone may appear to move several miles while the user remains inside one building, creating a spike that should not automatically be treated as a real trip.
A useful visualizer applies conservative filtering during rendering without rewriting the source. This distinction matters: the original history remains available for inspection, while the map view becomes easier to read. Review suspicious points individually instead of deleting them immediately.
Long-distance gaps create another challenge. A user may have only a departure point and an arrival point because the phone was offline, in airplane mode, or unable to record continuously. Drawing a straight line across a flat map can make an ocean crossing or international date-line route look misleading.
Globe-based rendering can use great-circle interpolation to represent the shortest path over a sphere. This creates a more natural arc for long-haul travel, although interpolation is still an estimate rather than proof of the exact route taken.
GPS Bounce
Isolated points far from the surrounding route may reflect weak reception or indoor positioning. Verify nearby timestamps before interpreting them.
Sparse Recording
Long gaps between points can hide the actual path. Treat connecting lines as visual estimates, not continuous tracking evidence.
Camera Follow
A stable map frame with a moving focal marker reduces rapid map movement and makes route videos easier to follow.
| Visual issue | Likely cause | Better interpretation |
|---|---|---|
| Sudden distant spike | GPS bounce or signal reflection | Check whether nearby points return immediately |
| Long straight segment | Missing pings during travel | Consider it an estimated connection |
| Route crossing the map edge | Projection or date-line behavior | Use globe-style rendering when available |
| Repeated stationary points | Indoor or background sampling | Group them by place and time |
| Missing activity label | No semantic classification in export | Use raw coordinates for route context |
For privacy-sensitive work, inspect which network requests occur when map imagery loads. Local parsing can keep the JSON on the device, but map tiles may still come from an external tile provider. The visualizer’s privacy notice should be read before the first map layer is requested.
A rendered line explains how the tool connects available points. It does not guarantee that every section of the route was recorded continuously.
Privacy, Long-Term Storage, and FAQ
A browser visualizer is useful for exploring exported history without signing into Google Maps. The referenced tool states that visualization occurs in the browser and that files are not sent elsewhere during ordinary viewing. An optional account-saving action is treated differently because it uploads data for import.
This makes the workflow suitable for one-time review, travel-memory projects, and route videos. It is less suitable as a permanent database for daily tracking. Users who need ongoing collection, searchable history, heat maps, or lifetime distance calculations may prefer a self-hosted spatial service that stores telemetry persistently.
The Google Timeline Visualizer tool page provides the browser upload workflow, supported file descriptions, and privacy details. Review the current notice before loading sensitive location data, especially when map tiles or optional cloud import features are enabled.
Before You Visualize:
- Keep an untouched copy of every exported JSON file
- Identify whether the data uses raw records, semantic history, or phone timeline structures
- Test one small file before combining multiple exports
- Check suspicious GPS spikes against nearby timestamps and places
- Read the privacy notice before loading external map tiles or using cloud import
| Workflow choice | Strength | Limitation |
|---|---|---|
| Browser visualizer | Fast, local, useful for retrospective viewing | Temporary session; not a persistent tracker |
| Raw records review | Detailed point-level inspection | Large files can be noisy and difficult to read |
| Semantic history review | Clear places and activity categories | Depends on the export containing semantic data |
| Self-hosted spatial database | Persistent queries, heat maps, and history | Requires setup, storage, and ongoing maintenance |
Q: What coordinate formats can a Google Timeline visualizer read?
Supported tools may read raw Records JSON with E7 integer coordinates, semantic location files, and newer phone exports containing nested timeline paths or semantic segments. Keep original keys and upload the file without manually rewriting fields.
Q: What are E7 coordinates?
E7 coordinates store latitude and longitude as scaled integers instead of ordinary decimal values. A schema-aware parser converts them before drawing points, so manual decimal placement is usually unnecessary and can introduce major errors.
Q: Can I combine multiple Google Timeline JSON files?
Yes, a visualizer can combine files from different export methods when they are supported. Start with separate tests because overlapping records may create duplicate points, repeated paths, or conflicting semantic details.
Q: Does the visualizer provide live location tracking?
No. This workflow is intended for reviewing exported history and rendering past routes. It does not continuously collect new GPS data or maintain an always-updated timeline unless you use a separate persistent tracking service.
Use the visualizer for private review and cinematic route rendering, then keep a separate encrypted backup if the history matters for long-term preservation.