APP-6 vs MIL-STD-2525: choosing a military symbology standard

Every military map display in NATO renders the same essential things: a friendly infantry company, a hostile armoured battalion, an unknown surface contact, a planned engagement area. Two standards govern how those things look — NATO's APP-6 and the United States' MIL-STD-2525. They share an ancestor, they overlap by roughly ninety-five percent, and they diverge in exactly the places that break your renderer. If you build C2 software for a coalition audience, you will eventually ship code that has to speak both. This is the engineering comparison: origins, version landscape, the symbol identification code, symbol sets, amplifiers, rendering, and the conversion edge cases that bite.

1. two standards, one ancestor

MIL-STD-2525 is the US Department of Defense standard for common warfighting symbology. APP-6 — Allied Procedural Publication 6, promulgated under STANAG 2019 — is the NATO standard. They descend from the same 1990s effort to give joint and combined forces a single visual language for the common operational picture, and for most of their history they were deliberately kept in lockstep. MIL-STD-2525A and APP-6A were siblings; 2525B aligned with APP-6B. The US document tended to lead, NATO ratified a closely matching version a year or two later, and national systems implemented whichever one their accreditation chain demanded.

The divergence that matters happened at the generational boundary. The US published MIL-STD-2525C in 2008 as the mature end-state of the original architecture. NATO then took the lead on the next-generation redesign, and the two communities co-developed the new model that shipped as MIL-STD-2525D (2014) and APP-6(D) (2017). So the lineage flips: for the legacy generation the US led; for the modern generation the standards re-converged on a jointly engineered design. The practical consequence is that 2525D and APP-6(D) are far closer to byte-for-byte equivalent than any earlier pairing — but you still have a large installed base of 2525C and APP-6(B) systems in the field that use a completely different code structure.

2. version landscape

Treat the standards as two families. The legacy family is MIL-STD-2525B/2525C and APP-6(A)/(B): a 15-character symbol identification code, a hierarchical letter-and-digit scheme, and a symbol catalogue organised around battle dimensions. The modern family is MIL-STD-2525D/2525E and APP-6(D): a 20-digit numeric code, a flat symbol-set architecture, and a substantially expanded entity catalogue.

The semantically aligned pairs are 2525C ↔ APP-6(B) on the legacy side and 2525D ↔ APP-6(D) on the modern side. 2525E (2022) extends the modern model with additional symbol sets — notably richer space, cyberspace, and unmanned-systems entities — without breaking the 20-digit structure, so an APP-6(D) renderer reads most 2525E codes correctly and simply falls back to an unknown entity for the new ones. Knowing which pair a given partner system implements is the first question to answer on any integration, because it decides whether you are doing a clean field-for-field map or a generational translation.

3. SIDC structure

The symbol identification code (SIDC) is the heart of both standards, and it changed completely between generations. The legacy SIDC is a 15-character string. Position 1 is the coding scheme, position 2 is the affiliation (friend, hostile, neutral, unknown, plus the assumed/suspect variants), position 3 is the battle dimension (air, ground, sea surface, subsurface, space, SOF), position 4 is status. Positions 5 through 10 are the function ID — a hierarchical letter code where each character narrows the entity, so an armoured-mechanised infantry unit and a generic infantry unit share a prefix and differ in the trailing characters. The remaining positions carry symbol modifiers and the echelon indicator. It is compact and human-readable once you memorise it, but it is rigid: there is no room left to add new entities without reusing slots.

The modern SIDC is 20 digits, purely numeric, and positional. Digits 1–2 are the version. Digit 3 is the standard identity context (reality, exercise, simulation). Digits 5–6 select the symbol set — the single most important field, because it routes everything that follows. Digits 7 carry status, 8 the headquarters/task-force/dummy indicator, 9–10 the amplifier descriptor. Digits 11–16 are the entity / entity-type / entity-subtype, a three-level numeric hierarchy. Digits 17–18 and 19–20 are the two modifier slots. The key insight from a parser's perspective: the modern code is a fixed-offset record, not a parsed string, which makes it far easier to validate and far harder to abuse than the legacy function-ID hierarchy.

4. symbol sets and entities

In the modern model, the symbol set (digits 5–6) is the dispatch key. The defined sets include air, air missile, space, space missile, land unit, land civilian, land equipment, land installation, control measures, sea surface, sea subsurface, mine warfare, activities, signals intelligence, and several unmanned and cyberspace sets added in later revisions. The symbol set determines the frame geometry, the valid entity codes, and the available amplifier fields all at once. A land-unit symbol uses the rectangle/quadrilateral frame family; a sea-surface symbol uses the ship's-hull frame; an air symbol uses the half-rounded "air" frame.

This is a cleaner separation than the legacy battle-dimension field, which conflated frame shape and entity domain. In the modern model the frame comes from affiliation plus symbol set, while the icon inside comes from the entity hierarchy. That orthogonality is exactly what makes a data-driven renderer practical: you build the frame from a handful of inputs and you look up the icon glyph from the entity digits, independently. This is the same separation-of-concerns discipline we describe in our deep dive on symbology engineering with MIL-STD-2525.

5. amplifiers and modifiers

The glyph is only half of a military symbol. The other half is the amplifier set — the text and graphic decorations placed around the frame, lettered fields A through Y in the standard. Field B is the echelon or mobility indicator drawn above the frame (the team/squad dots, the platoon/company/battalion bars, the brigade/division X marks). Field T is the unique designation — the unit's name or number. Field H is additional information, field W the date-time group, field J the evaluation rating, field C the quantity, field Q the direction-of-movement arrow, field AA the special headquarters staff indicator.

Status (present versus anticipated/planned) is rendered as a solid versus dashed frame — a small detail that an enormous number of renderers get wrong, because it has to apply to the frame stroke without affecting the fill or the icon. The headquarters indicator extends a staff line down from the frame; the task-force indicator wraps the frame in a bracket; the dummy/feint indicator adds a dashed extension. Echelon, HQ, task force, and status are independent flags in the modern SIDC, which means your amplifier engine has to compose them rather than switch on a single enumerated symbol type.

6. rendering

In practice almost nobody draws these symbols from the raw standard PDFs. The web ecosystem has standardised on milsymbol, the open-source JavaScript library maintained by Måns Beckman, which generates a military symbol as inline SVG directly from a SIDC plus an options object of amplifier values. You hand it a 20-digit (or legacy 15-character) code and a set of field values, and it returns a layered SVG: the frame path, the affiliation fill, the entity icon, and the surrounding amplifier text and graphics, each as separate elements you can style.

The layering is what makes it fast. Because the frame, fill, icon, and amplifiers are independent SVG layers, a renderer can cache the expensive parts (entity icon geometry) and recompute only the cheap parts (text amplifiers, colour) when a track updates. At C2 scale — thousands of tracks updating several times a second — you do not regenerate the whole symbol on every position update; you transform the cached SVG group and rewrite only the changed amplifier text. Pairing milsymbol's SVG output with a canvas or WebGL symbol layer is the standard approach to real-time map rendering on a moving common operational picture. milsymbol supports both 2525 and APP-6 frame styles via a single option, which is the cheapest way to satisfy a coalition customer who wants the NATO frame variant rather than the US one.

7. interconversion gotchas

Mapping a legacy 15-character SIDC to a modern 20-digit code is the conversion you will write, and it is lossy in both directions. The affiliation field maps cleanly enough — friend, hostile, neutral, unknown have direct counterparts — but the assumed-friend and suspect identities, and the joker/faker exercise variants, do not all survive a round trip intact. The battle dimension has to be re-expressed as a symbol set, and that is not one-to-one: the legacy "ground" dimension splits across land unit, land equipment, and land installation in the modern model, so you cannot infer the target symbol set from the dimension digit alone — you have to inspect the function ID.

The function-ID hierarchy is the worst offender. Several legacy entities have no exact modern entity and several modern entities (especially the newer cyberspace and unmanned sets) have no legacy code at all, so they degrade to a generic entity on the way down. Echelon usually survives; mobility indicators sometimes do not. The safe engineering posture is to carry the original SIDC verbatim as a stored attribute and treat the converted code as a render-time derivation, never as the system of record — that way a future correction to your mapping table re-renders the whole picture without data migration.

8. choosing for your C2 product

The decision is rarely about which standard is "better" — they encode the same doctrine. It is about who consumes your output. If your operators and your coalition partners run NATO systems, render the APP-6 frame variant by default; if you integrate tightly with US programs, default to MIL-STD-2525. Releasability matters here too: the symbology itself is unclassified, but the entities you populate and the SIDC variants you support should track what your partners' accredited systems actually render, so you do not push a symbol that shows up blank on an ally's screen.

The pattern that ages well is the dual-render strategy: store every track with its modern 20-digit SIDC as the canonical identity, keep a frame-style flag (2525 vs APP-6) as a display preference, and let the symbol layer emit either on demand. Because milsymbol switches frame styles from one option, the incremental cost of supporting both is near zero once your data model is clean. Build the symbol pipeline as a thin, well-tested mapping layer over a single canonical code, treat conversion tables as versioned data rather than hard-coded logic, and you will absorb the next revision — 2525F, APP-6(E) — as a table update instead of a rewrite. For the wider architectural context, see our complete guide to C2 systems.