TLE – JSON satellite orbit converter

Use this free online converter to transform amateur radio satellite orbital data between traditional TLE/3LE text files and the newer GP JSON format. Upload a TXT, TLE or JSON file, or paste the orbital data directly into the converter. The tool supports both conversion directions and processes all data locally in your browser.

From TLE files to GP JSON: why satellite orbital data is changing

For decades, amateur radio operators have downloaded small text files containing satellite names followed by two dense lines of numbers. These files are commonly called TLE files, Two-Line Elements, 3LE files, “Keplerian elements” or simply “keps.” They are used by satellite tracking software to calculate where a spacecraft should appear in the sky, when it will rise above the horizon, how high it will travel and when a pass will end.

The format has survived because it is compact, predictable and supported by almost every established satellite-tracking program. A complete orbital record can be stored in little more than 140 characters, transferred over a slow connection and parsed by software written decades ago.

However, the satellite catalogue has grown far beyond what the original fixed-width format was designed to handle. Newly catalogued objects are moving into six-digit identification numbers, while the traditional TLE format reserves only five character positions for the catalogue number. As a result, new satellites cannot always be distributed reliably in conventional TLE form.

This is why organisations such as AMSAT are beginning to distribute amateur satellite orbital elements in modern formats including JSON, XML and KVN, while continuing to provide traditional TLE bulletins for older satellites that remain compatible with the legacy format.

The important point is that the physics is not being replaced. The underlying General Perturbations orbital data and the SGP4 propagation model remain central to satellite tracking. What is changing is the container used to store and exchange the information.

What amateur satellite operators used until now

The familiar amateur satellite orbital-data file normally contains either two or three lines for each spacecraft.

A two-line record contains only the two formal TLE lines:

1 25544U 98067A   24123.50000000  .00016717  00000-0  30118-3 0  9995
2 25544  51.6400  78.1234 0004567 123.4567 321.6543 15.50000000123456

A three-line record adds a human-readable satellite name above them:

ISS (ZARYA)
1 25544U 98067A   24123.50000000  .00016717  00000-0  30118-3 0  9995
2 25544  51.6400  78.1234 0004567 123.4567 321.6543 15.50000000123456

The name line is sometimes called line zero, which is why a file containing a name plus two element lines is often described as a 3LE file. Without the name, it is normally called a 2LE record.

In amateur radio practice, the terms TLE, 2LE, 3LE and Keplerian elements are frequently used loosely. Strictly speaking, the actual orbital element set is contained in lines one and two. The name line is an additional label used to make the file easier for humans and tracking applications to navigate.

These records are not a list of predicted positions. They do not say that a satellite will be above Budapest at a particular clock time. Instead, they describe the spacecraft’s orbit at a specific epoch. Tracking software feeds these values into the SGP4 orbital propagation model, combines them with the observer’s coordinates and calculates the satellite’s position for the requested time.

AMSAT describes TLEs as inputs to the standard SGP4 mathematical model used by most amateur satellite tracking programs. For many amateur spacecraft, regularly updated element sets remain adequate for practical pass prediction, antenna pointing and Doppler calculations.

Why the traditional format lasted so long

The TLE format dates from an era when every character mattered. Storage was expensive, communications links were slow and computer systems often processed fixed-column records far more easily than complex structured documents.

Its fixed-width design offered several practical advantages:

• every important value appeared at a known character position;
• a record could be read without transmitting field names;
• files remained extremely small;
• checksums helped detect damaged or mistyped lines;
• early software could parse the format with simple substring operations;
• the same records could be exchanged across many different computer systems.

The format became deeply embedded in tracking applications, command-line utilities, rotator-control programs, radio Doppler tools, observatory software and custom amateur radio projects.

A home-built satellite tracker written years ago for a microcontroller may expect exactly 69 characters on line one and exactly 69 characters on line two. A desktop tracking program may scan a large file three lines at a time. A web service may recognise a satellite by reading characters 3 through 7 from each TLE line.

This enormous installed base explains why TLE files will not disappear overnight. They remain useful for the many existing satellites whose catalogue identifiers still fit within the format. AMSAT has stated that it will continue publishing traditional TLE bulletins indefinitely for satellites catalogued before the transition to six-digit identifiers.

Why the format now needs to change

The most immediate problem is the satellite catalogue number.

A conventional TLE allocates five positions to the catalogue identifier. This allows ordinary numeric values from 00000 to 99999. The space-object catalogue is now reaching the point where new objects require identifiers of 100000 and above.

The problem cannot be solved simply by inserting another digit. TLE is a fixed-column format. Adding one character near the beginning of a line would move every later field and break software that relies on the historic column positions.

Space-Track explains that objects in catalogue-number ranges below 100000 can continue to be made available in legacy fixed-width TLE or 3LE form, while the old format does not support catalogue numbers above 99999. Current and historical General Perturbations data remain available through modern GP and GP_History services in formats including OMM XML, OMM KVN, JSON and CSV.

CelesTrak similarly warns that newly catalogued objects with six-digit numbers will not be available in TLE format and provides GP data through modern alternatives.

The catalogue-number limit is the trigger for the present transition, but it is not the only weakness of TLE.

The format also suffers from:

• fixed numerical precision;
• abbreviated two-digit years;
• implied decimal points;
• specialised exponent notation;
• limited metadata;
• rigid column positions;
• poor extensibility;
• values that are difficult for humans to interpret without documentation;
• ambiguity when records are copied with missing spaces or damaged line endings.

A modern structured format can use full field names, longer identifiers, standard timestamp notation, ordinary floating-point numbers and additional metadata without shifting the location of every other value.

The temporary Alpha-5 solution

Before six-digit catalogue numbers became unavoidable, an intermediate system called Alpha-5 was introduced. It replaces the first digit of certain five-character satellite-number fields with a letter.

For example, a catalogue number above 99999 can be represented using one letter followed by four digits. This preserves the five-character width of the TLE catalogue field and allows some existing software to continue operating after relatively small modifications.

Alpha-5 extends the useful range of the legacy format, but it is not a permanent solution.

Older tracking software may assume that the satellite identifier contains digits only. Database columns may be configured as integers. Scripts may attempt to convert the field directly into a number and fail when they encounter a letter. Some applications may accept Alpha-5 input but display or sort the identifier incorrectly.

More importantly, even the extended Alpha-5 range is finite. It does not transform TLE into a generally extensible format, and it does not address the other limitations of fixed-width records.

The move toward GP JSON, OMM XML, OMM KVN and CSV is therefore more than a workaround for one extra digit. It creates a data-delivery system capable of supporting much larger identifiers and richer metadata.

What remains the same after the transition

The change from TLE text to GP JSON may initially look like a completely new orbital system. In practice, many of the most important values remain recognisable.

Both formats can describe fields such as:

• the satellite catalogue number;
• the international designator;
• the epoch of the element set;
• inclination;
• eccentricity;
• right ascension of the ascending node;
• argument of pericentre;
• mean anomaly;
• mean motion;
• the first and second derivatives of mean motion;
• the BSTAR drag term;
• the element-set number;
• the revolution number at epoch.

The modern JSON representation is commonly based on field names associated with the CCSDS Orbit Mean-Elements Message, or OMM. CelesTrak’s JSON format uses OMM keywords and definitions, although fields that are empty, redundant or fixed to standard values may be omitted.

Consequently, converting a compatible TLE record to GP JSON is largely a matter of:

1. reading each fixed-width TLE field;
2. interpreting special notation correctly;
3. expanding abbreviated dates and identifiers;
4. assigning each value to a named JSON property;
5. writing the resulting object or array.

The reverse process is possible when the JSON values fit within the limits of conventional TLE. The software must compress the data back into exact field widths, recreate implied decimal and exponent notation, shorten the epoch year and calculate new line checksums.

Understanding a TLE or 3LE file

A TLE file looks cryptic because it contains almost no labels. The meaning of each value is determined by its exact location.

Consider this simplified three-line record:

AO-91
1 43017U 17073E   24123.43750000  .00001420  00000-0  15700-3 0  9991
2 43017  97.7250 145.2000 0259000 250.4000 106.9000 14.76900000349001

The first line is the satellite name. It is not part of the formal two-line element set, but it is useful for software menus and human identification.

The next two lines contain the actual GP element data.

The satellite name line

The optional first line normally contains a familiar spacecraft name or amateur radio designation, such as:

AO-91

or:

ISS (ZARYA)

This line may also begin with the number zero in some 3LE files:

0 AO-91

The name is a label rather than an orbital parameter. Changing the label does not alter the calculated orbit. However, duplicate, inconsistent or outdated names can create confusion when data is imported into tracking applications.

JSON normally stores the same information in a property such as:

"OBJECT_NAME": "AO-91"

Unlike the fixed-width TLE lines, JSON can represent longer names without disturbing other orbital fields.

TLE line one

Line one contains identification information, the epoch and several parameters connected with orbital evolution and the SGP4 model.

A typical line looks like this:

1 43017U 17073E   24123.43750000  .00001420  00000-0  15700-3 0  9991

Each field has a specific meaning.

Line number

The first character is:

1

This identifies the record as TLE line one. Tracking software often uses it to confirm that the file is aligned correctly.

Satellite catalogue number

The next field contains the catalogue identifier:

43017

The corresponding JSON property is normally:

"NORAD_CAT_ID": 43017

This identifier is one of the main reasons for the transition. A numeric value such as 43017 fits comfortably into the five-character TLE field. A new identifier such as 100123 does not.

JSON does not depend on fixed character positions and can therefore store longer identifiers directly:

"NORAD_CAT_ID": 100123

Some GP services are designed to support catalogue numbers considerably longer than six digits. CelesTrak’s newer data interfaces include support for identifiers of up to nine digits, while legacy TLE, 2LE and 3LE output remains limited by the old catalogue field.

Classification

The character immediately following the catalogue number is the classification:

U

The most familiar value is U, meaning unclassified.

The JSON equivalent is:

"CLASSIFICATION_TYPE": "U"

Supplemental GP datasets may use other values to indicate a different data source. CelesTrak, for example, uses classification information to distinguish certain supplemental owner/operator-provided element sets from regular Space-Track GP data.

International designator

A field such as:

17073E

identifies the launch year, launch number within that year and the piece associated with the launch.

In expanded form, the JSON object identifier may appear as:

"OBJECT_ID": "2017-073E"

This tells us that the object came from the 73rd launch of 2017 and was assigned the piece designation E.

The international designator is different from the NORAD catalogue number. The catalogue number is a sequential object identifier, whereas the international designator links the object to a particular launch.

Epoch

A TLE epoch may look like:

24123.43750000

The first two digits represent the year:

24

The remaining value represents the day of the year plus a fractional day:

123.43750000

This means day 123 of 2024, with the decimal fraction specifying the time within that UTC day.

The format is compact but not especially readable. It also inherits a two-digit-year convention. Traditional interpretation maps years from 57 through 99 to 1957–1999 and years from 00 through 56 to 2000–2056. This creates a future date-range problem in addition to the catalogue-number issue.

In JSON, the same epoch can be written as a full ISO-style UTC timestamp:

"EPOCH": "2024-05-02T10:30:00.000000"

or, depending on the provider:

"EPOCH": "2024-05-02T10:30:00.000000Z"

The structured form is longer, but it is much clearer. The year is explicit, the month and date are immediately recognisable and standard date libraries can usually parse the value without specialised TLE logic.

First derivative of mean motion

A field such as:

.00001420

represents one half of the first time derivative of mean motion in the traditional TLE convention.

In OMM-style JSON, the corresponding value is commonly stored under:

"MEAN_MOTION_DOT": 0.0000284

A correct converter must account for the factor-of-two difference. Simply copying the visible TLE number into MEAN_MOTION_DOT would produce a mathematically inconsistent JSON record.

This field reflects the changing orbital rate, which can be influenced by effects such as atmospheric drag. It is part of the historical TLE representation, although practical SGP4 processing is particularly associated with the BSTAR term.

Second derivative of mean motion

The next field may look unusual:

00000-0

This is a compact exponent format with an implied decimal point. A non-zero example might look like:

12345-5

The value must be interpreted as a mantissa and exponent rather than as ordinary decimal notation.

The corresponding JSON property is:

"MEAN_MOTION_DDOT": 0

As with the first derivative, conversion requires attention to the TLE convention. The TLE field represents one sixth of the second derivative, whereas OMM-style data can store the full derivative.

For most amateur satellite records, this value is often zero or extremely small, but a converter must still parse and regenerate it correctly.

BSTAR drag term

A field such as:

15700-3

is another implied-decimal exponent value.

It corresponds to a numerical value such as:

"BSTAR": 0.000157

BSTAR is a drag-like parameter used by the SGP4 model. It should not be interpreted as a direct, universally precise measurement of the spacecraft’s physical ballistic coefficient. It is part of the model fit associated with the element set.

Low-Earth-orbit satellites are affected by atmospheric drag, and the effect changes with altitude, atmospheric density, solar activity and spacecraft characteristics. This is one reason orbital element sets must be refreshed periodically rather than treated as permanent descriptions of an orbit.

Ephemeris type

The next field is usually:

0

The JSON equivalent is:

"EPHEMERIS_TYPE": 0

In standard public TLE practice, zero is the common value.

Element-set number

Near the end of line one is the element-set number:

999

In JSON:

"ELEMENT_SET_NO": 999

This field can help distinguish successive element sets for the same object, although users should not assume that every provider or supplemental data source applies it identically.

Checksum

The final digit is the line-one checksum.

The TLE checksum is calculated by adding all numerical digits in the first 68 characters. Minus signs contribute one, while letters, spaces, plus signs and decimal points contribute zero. The result modulo ten becomes the final checksum digit.

The checksum can detect many damaged or mistyped lines, but it is not a cryptographic integrity mechanism. It does not guarantee that the orbit is correct, recent or associated with the right satellite.

JSON normally does not reproduce this checksum because it is specific to the fixed-width TLE line. When JSON is converted back into TLE, the software must calculate a new checksum from the newly formatted line.

TLE line two

Line two contains the principal orbital elements used to describe the shape and orientation of the orbit.

A typical line looks like this:

2 43017  97.7250 145.2000 0259000 250.4000 106.9000 14.76900000349001

Line number and catalogue number

The line begins with:

2 43017

The first character identifies line two. The catalogue number must match the catalogue number in line one.

A mismatch may indicate a damaged file, a copy-and-paste error or lines from two different satellites being combined accidentally. A robust converter should reject the record rather than silently generating a misleading JSON object.

Inclination

The inclination field may be:

97.7250

In JSON:

"INCLINATION": 97.725

Inclination is the angle between the orbital plane and Earth’s equatorial plane.

An orbit near zero degrees is close to equatorial and prograde. An inclination near 90 degrees is nearly polar. Values above 90 degrees describe retrograde motion.

Many small Earth-observation and amateur satellites are placed in high-inclination or sun-synchronous-type low-Earth orbits, which allows them to pass over a large range of latitudes.

Right ascension of the ascending node

The next value might be:

145.2000

The JSON property is:

"RA_OF_ASC_NODE": 145.2

This is often abbreviated as RAAN.

The ascending node is the point where the spacecraft crosses Earth’s equatorial plane from south to north. The right ascension of that node describes the orientation of the orbital plane around Earth.

Inclination tells us how much the orbital plane is tilted. RAAN tells us how that tilted plane is rotated around the planet.

Eccentricity

In a TLE, eccentricity is written without a decimal point:

0259000

It must be interpreted as:

0.0259000

In JSON, the decimal point is explicit:

"ECCENTRICITY": 0.0259

Eccentricity describes the shape of the orbit.

A value of zero represents a perfect circle. Small positive values describe slightly elliptical orbits. Values closer to one describe increasingly elongated bound orbits.

The missing decimal point is a classic example of why TLE parsing cannot be treated as ordinary whitespace-separated text. The field must be read according to the format specification.

Argument of pericentre

The next field might contain:

250.4000

In JSON:

"ARG_OF_PERICENTER": 250.4

The argument of pericentre describes the orientation of the orbit’s closest point within the orbital plane. In Earth-orbit terminology, the closest point is often called perigee.

RAAN establishes the orientation of the orbital plane. The argument of pericentre then describes how the ellipse is rotated inside that plane.

For a nearly circular orbit, the exact physical significance of pericentre orientation becomes less intuitive because there is little difference between the closest and farthest points.

Mean anomaly

A value such as:

106.9000

becomes:

"MEAN_ANOMALY": 106.9

Mean anomaly specifies where the spacecraft is in its orbital cycle at the epoch, expressed through the mathematical framework of orbital motion.

It should not be confused with a simple geographic longitude. It is an angular parameter within the orbital model and must be combined with the other elements to calculate the spacecraft’s position.

Mean motion

The field:

14.76900000

becomes:

"MEAN_MOTION": 14.769

Mean motion is expressed in revolutions per day.

A value of approximately 15 means that the spacecraft completes roughly 15 orbits every 24 hours. Dividing 1440 minutes by the mean motion provides a quick estimate of the orbital period:

1440 ÷ 14.769 ≈ 97.5 minutes

This is typical of a low-Earth-orbit satellite.

Mean motion is one of the most immediately informative values in the file. It offers a quick indication of the orbital period and, indirectly, the general orbital regime.

Revolution number at epoch

Near the end of line two is the revolution number:

34900

The JSON equivalent is:

"REV_AT_EPOCH": 34900

This is a count associated with the spacecraft’s revolutions at the time of the element-set epoch. It is useful as metadata, but it is not normally the primary field used to identify or propagate the orbit.

Line-two checksum

As on line one, the final character is a checksum calculated from the preceding 68 positions.

When a JSON record is converted into TLE, every field must first be formatted into the exact conventional width. Only then can the final checksum be calculated.

Even a harmless-looking spacing change alters character positions and can produce an invalid TLE record.

How GP JSON is structured

A GP JSON file looks dramatically different because it names every property.

A single satellite may appear as an object like this:

{
  "OBJECT_NAME": "AO-91",
  "OBJECT_ID": "2017-073E",
  "EPOCH": "2024-05-02T10:30:00.000000",
  "MEAN_MOTION": 14.769,
  "ECCENTRICITY": 0.0259,
  "INCLINATION": 97.725,
  "RA_OF_ASC_NODE": 145.2,
  "ARG_OF_PERICENTER": 250.4,
  "MEAN_ANOMALY": 106.9,
  "EPHEMERIS_TYPE": 0,
  "CLASSIFICATION_TYPE": "U",
  "NORAD_CAT_ID": 43017,
  "ELEMENT_SET_NO": 999,
  "REV_AT_EPOCH": 34900,
  "BSTAR": 0.000157,
  "MEAN_MOTION_DOT": 0.0000284,
  "MEAN_MOTION_DDOT": 0
}

A file containing multiple satellites generally uses a JSON array:

[
  {
    "OBJECT_NAME": "AO-91",
    "NORAD_CAT_ID": 43017,
    "EPOCH": "2024-05-02T10:30:00.000000",
    "MEAN_MOTION": 14.769
  },
  {
    "OBJECT_NAME": "ISS (ZARYA)",
    "NORAD_CAT_ID": 25544,
    "EPOCH": "2024-05-02T12:00:00.000000",
    "MEAN_MOTION": 15.5
  }
]

The square brackets indicate an array. Each pair of curly brackets contains one satellite record. Properties are written as name-and-value pairs separated by commas.

This structure is natural for JavaScript, Python, PHP, Java, C#, Go and many other programming environments. A developer no longer needs to remember that inclination begins at a particular character position. The software can request the value named INCLINATION.

Core identification fields in JSON

The main identification properties are usually:

"OBJECT_NAME": "AO-91"

"OBJECT_ID": "2017-073E"

"NORAD_CAT_ID": 43017

"CLASSIFICATION_TYPE": "U"

These fields identify the object, connect it to its launch and provide classification information.

The key advantage is extensibility. A longer catalogue number can be stored without changing the position or interpretation of any other field.

Core epoch and orbital fields

The principal orbital fields are:

"EPOCH": "2024-05-02T10:30:00.000000"

"MEAN_MOTION": 14.769

"ECCENTRICITY": 0.0259

"INCLINATION": 97.725

"RA_OF_ASC_NODE": 145.2

"ARG_OF_PERICENTER": 250.4

"MEAN_ANOMALY": 106.9

Together, these describe the orbit at the stated epoch in a form suitable for the associated propagation model.

Because the properties are explicitly named, the file is far easier to inspect and debug than a fixed-width TLE. A developer can also add validation rules based on realistic numerical ranges.

For example:

• inclination should normally fall between 0 and 180 degrees;
• eccentricity for an ordinary bound Earth orbit should be at least zero and less than one;
• mean motion should be positive;
• angular fields can be normalised to a range from 0 to 360 degrees;
• the epoch should be a valid date and time.

Model-related fields

Fields associated with the GP and SGP4 representation include:

"BSTAR": 0.000157

"MEAN_MOTION_DOT": 0.0000284

"MEAN_MOTION_DDOT": 0

"EPHEMERIS_TYPE": 0

These values correspond to information stored compactly on TLE line one.

JSON uses ordinary numerical notation, eliminating the need for TLE’s implied decimal points and specialised exponent fields.

Additional OMM metadata

An OMM-style record may also include standard metadata such as:

"CENTER_NAME": "EARTH"

"REF_FRAME": "TEME"

"TIME_SYSTEM": "UTC"

"MEAN_ELEMENT_THEORY": "SGP4"

These fields make assumptions explicit.

A traditional TLE does not need to repeat that the model is Earth-centred, uses UTC-related epoch handling and is associated with SGP4 conventions because those assumptions are built into the format and its use.

Modern structured records can carry them as named metadata. However, some JSON providers omit fields that are fixed, redundant, blank or otherwise unnecessary for their service. CelesTrak notes that its JSON output uses OMM keywords but may exclude redundant mandatory values such as CENTER_NAME = EARTH, REF_FRAME = TEME, TIME_SYSTEM = UTC and MEAN_ELEMENT_THEORY = SGP4.

Software should therefore avoid assuming that every possible OMM field will always be present in every JSON file.

JSON, OMM and GP are related but not identical terms

The terminology can be confusing.

GP means General Perturbations. It refers to the family of orbital element data used with simplified perturbation models such as SGP4.

OMM means Orbit Mean-Elements Message. It is a CCSDS-defined structure for exchanging mean orbital elements.

JSON is a general-purpose data-serialization syntax. It defines how objects, arrays, strings and numbers are written, but it does not itself define what an orbital field means.

A GP JSON file therefore uses JSON syntax to carry GP orbital data, usually with property names and definitions based on OMM.

Other containers can carry much of the same information:

• OMM XML uses XML tags;
• OMM KVN uses keyword-value notation;
• JSON uses objects and arrays;
• CSV uses columns and rows;
• TLE uses fixed character positions.

CelesTrak’s query interfaces list TLE/3LE, 2LE, OMM XML, OMM KVN, JSON, pretty-printed JSON and CSV as available GP-data representations.

The choice of format affects storage and parsing, not the fundamental identity of the satellite or the physical orbit represented by the data.

Why JSON is useful for websites and software

JSON is especially well suited to online satellite tools.

A browser can load a JSON array and immediately turn it into JavaScript objects. A program can filter satellites by catalogue number, search by name, sort by epoch or send a selected object to a propagation library.

A typical workflow may look like this:

1. download a current GP JSON file;
2. parse the JSON array;
3. select the required amateur satellite;
4. check the element-set epoch;
5. pass the orbital values to an SGP4 implementation;
6. calculate azimuth, elevation, range and Doppler shift;
7. display the result on a web page or tracking interface.

Compared with TLE parsing, the software is less dependent on character positions and unusual numerical notation.

JSON is also convenient for APIs. An API can return one satellite, a filtered group or thousands of objects using the same basic structure. Additional fields can be included without making the entire file unreadable to newer applications.

Why TLE is still useful

Modern does not automatically mean better for every purpose.

TLE remains:

• extremely compact;
• widely supported;
• easy to distribute as plain text;
• compatible with established amateur radio programs;
• suitable for older satellites with five-digit identifiers;
• convenient for manual copying into legacy software;
• familiar to operators and developers.

Many satellite programs cannot yet import GP JSON directly. Some support only a URL pointing to a TLE file. Others store element sets internally as two text lines regardless of the original source format.

For these applications, conversion remains valuable.

A GP JSON-to-TLE converter can act as a compatibility bridge when the record remains representable in conventional TLE. A TLE-to-JSON converter can help developers move older datasets into modern software, databases and web tools.

However, conversion should not create the impression that every modern GP record can be forced into the old format.

When JSON cannot be converted back to conventional TLE

A lossless conversion from GP JSON to TLE is possible only when all required values fit within TLE’s technical limits.

Conversion may fail or lose information when:

• the catalogue number cannot fit into the five-character TLE identifier field;
• the epoch lies outside the conventional two-digit-year interpretation range;
• a number requires greater precision than the TLE field permits;
• a value is too large for the available column width;
• metadata has no TLE equivalent;
• the object is not represented using assumptions compatible with conventional Earth-orbit SGP4 TLE data;
• additional provider-specific fields must be preserved.

The catalogue number is currently the most visible limitation. New six-digit objects are the central reason modern formats are becoming necessary.

A converter must therefore report an error rather than truncate an identifier. Turning 100123 into 00123 would not be a minor formatting issue. It would point to an entirely different catalogue object.

Precision and round-trip conversion

A TLE-to-JSON conversion can represent the values decoded from the original TLE. However, converting that JSON back to TLE does not guarantee that every character will be identical to the original file.

Several factors may change the text:

• numbers may be rounded to the permitted TLE precision;
• spacing may be regenerated;
• checksums will be recalculated;
• a missing name may be replaced with a generated label;
• optional metadata may be normalised;
• date formatting may pass through a full timestamp representation;
• equivalent exponent values may be formatted differently.

The regenerated TLE can still represent the same practical element set within the limits of the format.

By contrast, metadata that exists only in JSON cannot survive a round trip through TLE. Once the record is compressed into two fixed-width lines, unsupported properties are lost unless they are stored separately.

For archiving, the richest original source format should therefore be retained.

Freshness matters more than file type

A perfectly formatted orbital file may still produce poor predictions if its epoch is old.

Low-Earth-orbit satellites experience atmospheric drag and other perturbations. The orbit predicted from an old element set gradually diverges from the spacecraft’s actual position. The rate of divergence varies by object, altitude, manoeuvres, atmospheric conditions and data quality.

For casual amateur satellite operation, regularly updated elements are usually sufficient. More demanding tasks, such as narrow-beam antenna tracking, high-frequency Doppler correction or operations shortly after a launch or manoeuvre, may require fresher data.

The move to JSON does not eliminate the need for updates. JSON is a more flexible transport format, not a permanently accurate orbit.

Users should always check:

• the epoch of the record;
• the reliability of the source;
• whether the spacecraft has manoeuvred;
• whether the object identification is confirmed;
• whether the tracking software supports the data correctly.

Checksums are not orbital validation

The TLE checksum verifies only a simple property of the text line.

A line can have a correct checksum and still contain:

• obsolete orbital data;
• the wrong satellite name;
• a valid record for a different object;
• inaccurate fitted elements;
• manually altered values with a recalculated checksum.

Similarly, valid JSON syntax means only that the document follows JSON grammar. It does not prove that the orbital values are sensible or current.

A reliable converter should perform several levels of checking:

• valid file syntax;
• valid TLE line numbering;
• matching catalogue numbers on both TLE lines;
• expected line lengths;
• checksum verification;
• required JSON fields;
• numerical data types;
• reasonable orbital ranges;
• supported catalogue identifiers;
• valid epoch values.

Even then, authoritative source selection and data freshness remain the user’s responsibility.

What changes for amateur radio operators

For many operators, the transition will initially be almost invisible.

Older satellites will continue to appear in familiar TLE bulletins. Existing tracking applications will continue to work with those files. Weekly or daily element updates will remain part of normal station operation.

The difference will become more visible when newly launched amateur satellites receive catalogue identifiers that cannot be represented in ordinary TLE form.

At that point, one of three things must happen:

1. tracking software gains native support for GP JSON, OMM XML, OMM KVN or another modern format;
2. an intermediate service converts compatible data into a format accepted by the application;
3. the user moves to software that supports the new catalogue and data formats.

Not every new record will be convertible to legacy TLE. For truly incompatible catalogue numbers, updating the software is the only correct long-term solution.

What changes for software developers

Developers should begin treating TLE as one supported input format rather than the universal definition of orbital data.

A future-proof satellite application should ideally separate three tasks:

Data import

This layer reads TLE, JSON, XML, KVN or CSV and converts the source into an internal orbital-record object.

Data validation

This layer checks identifiers, timestamps, required values and numerical ranges.

Orbit propagation

This layer passes the normalised values to an appropriate SGP4 implementation and calculates positions.

Separating these responsibilities prevents the user interface, database and orbital engine from depending on one particular text layout.

Developers should also store catalogue identifiers in a field large enough for future growth. A five-digit integer or five-character string is no longer sufficient. Even when current amateur satellites use smaller numbers, the database should not recreate the limitation that modern formats are designed to remove.

What changes for online data services

Modern formats allow orbital-data services to provide richer and more flexible responses.

A service can return:

• one object by catalogue number;
• a named group of amateur satellites;
• all active spacecraft;
• historical element sets;
• supplemental owner/operator data;
• additional quality or source information;
• records containing longer identifiers.

CelesTrak notes that some information, including certain fit-quality and source-related values in supplemental services, may be available specifically through CSV and JSON outputs rather than legacy TLE.

This shows why the transition is not merely a cosmetic reformatting. Structured formats can carry information that the old 69-character lines were never designed to hold.

Practical use of this converter

The converter above provides a bridge between traditional amateur satellite files and modern GP JSON data.

For TLE or 3LE to JSON conversion:

1. select the TLE-to-JSON direction;
2. upload a .txt or .tle file, or paste the orbital records;
3. start the conversion;
4. inspect the generated JSON;
5. copy or download the result.

For GP JSON to TLE conversion:

1. select the JSON-to-TLE direction;
2. upload a .json file, or paste a JSON object or array;
3. start the conversion;
4. review any compatibility warning;
5. download the generated TLE or 3LE text.

The conversion takes place locally in the browser. The selected file does not need to be uploaded to a remote conversion server.

This is useful when working with:

• amateur satellite tracking programs;
• rotator-control systems;
• Doppler-correction tools;
• custom JavaScript applications;
• Python satellite scripts;
• orbital databases;
• WordPress satellite tools;
• embedded and microcontroller projects;
• archived Keplerian-element collections;
• software migration and testing.

Choosing the correct output format

Use traditional TLE or 3LE when:

• the destination program accepts only TLE;
• the satellite has a compatible catalogue identifier;
• compact file size is important;
• legacy software support is required;
• no additional metadata must be preserved.

Use GP JSON when:

• the catalogue number may exceed the TLE limit;
• the data will be processed by a website or API;
• clear property names are preferred;
• additional metadata must be retained;
• several records must be filtered or manipulated programmatically;
• future compatibility is more important than legacy file size.

Use OMM XML or KVN when a particular engineering, institutional or operational system expects those CCSDS-oriented representations.

There is no universal need to convert every archive immediately. A practical strategy is to keep original files, support both old and new formats and use conversion only when required by the destination software.

The end of TLE or the beginning of coexistence?

The arrival of GP JSON does not mark the immediate end of Two-Line Elements.

TLE remains one of the most successful and widely implemented orbital-data exchange formats ever created. Its compact design allowed generations of professional and amateur users to track spacecraft with modest computers and simple communication links.

Its present limitation is not evidence that the format failed. It is evidence that the space catalogue grew far beyond the scale imagined when the format was designed.

The next phase will therefore be a period of coexistence.

Traditional TLE and 3LE files will continue serving older satellites and legacy tracking software. GP JSON, OMM XML, OMM KVN and CSV will handle larger catalogue identifiers, clearer timestamps, richer metadata and modern software workflows.

For amateur radio operators, the essential task remains unchanged: obtain current orbital elements, load them into compatible software and use them to predict passes, point antennas and compensate for Doppler shift.

The difference is that the familiar two lines of compressed numbers are no longer the only practical way to deliver that information.

The orbit has not changed because it is written in JSON. The data has simply moved into a container built for the much larger satellite catalogue that now surrounds Earth.

Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.

This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you.