Open the feature list of almost any chord-sheet app and you will find the same two words: "ChordPro support." It is table stakes now, and honestly that is a good thing. ChordPro is an open, plain-text standard, and the more apps that read it, the safer your library is.
But "supports ChordPro" covers a lot of ground, because ChordPro is a bigger format than most people realize. Inline chords are the part everyone knows. The spec goes a long way past that, and how far an app follows it varies. That is not a scandal, most apps implement what their users actually paste in. It is just worth understanding, especially if you are about to move a whole library across and want to know what will survive the trip.
So here is the full picture, tier by tier, including the parts Fretlist does well and the parts it still doesn't. I have spent a long time on Fretlist's ChordPro handling, so I will be specific.
Tier 1: inline chords
The core of ChordPro is one idea: chord names go inline with the lyrics, in square brackets, at the exact spot the chord should sound.
[G]Hello [D]darkness my [Em]old [C]friendEvery app that reads ChordPro handles this, and any file that only uses inline chords renders the same everywhere. If you want the full syntax walk-through, I wrote a complete ChordPro guide separately. Tier 1 is not where apps differ. The rest is.
Tier 2: directives and metadata
Next come directives, the {curly brace} tags that carry metadata and structure:
{title: Sound of Silence}
{artist: Simon & Garfunkel}
{key: Em}
{capo: 2}The common ones are widely read. The long tail is where it gets patchy: {composer}, {lyricist}, {subtitle}, comment styles like comment_box and comment_italic, and the ALL-CAPS titles some exports produce. Fretlist splits a combined {title: SONG - Artist} into a real title and artist, title-cases shouty exports, and keeps the comment styles instead of flattening them. Small things, but they add up to a clean import versus an afternoon of fixups.
Tier 3: environments
ChordPro marks sections, using environments: a start directive, some lines, an end directive.
{start_of_verse}
[Em]Hello [D]darkness my [Em]old friend
{end_of_verse}
{start_of_tab}
e|-----------------|
B|-----------------|
G|-------------0-2-|
D|-----0-2-4-------|
A|-0-3-------------|
E|-----------------|
{end_of_tab}Verse, chorus, bridge, tab. The interesting question is whether an app keeps the structure or just reads the label. A tab environment, for instance, only works if the columns stay aligned and a chord line above the tab merges with it. And there is a second half people forget: support is not just reading, it is writing. An app that imports {start_of_verse} but exports plain text has lost the structure, and your library degrades a little every round trip. Fretlist keeps the environments intact both directions, labels and all.
Tier 4: the grid environment
Here is the part that got me into this. ChordPro has a grid environment for charting a song as bars and chords with no lyrics, the way a lead sheet works:
{start_of_grid label="Outro" shape="1+4x2+1"}
A |: C . | F G | Am7 F | Dm . :|
Volta 1 |1 C7 . | C . :|
Volta 2 |2 G7 . | C . |
{end_of_grid}Read it closely. There is a repeat (|: … :|), two chords in one bar (F G), first and second endings (the |1 and |2 voltas), a section label on the left margin, and empty beats marked with dots. This is real musical notation living in a plain-text file, and it is genuinely harder to render than lyrics with chords over them.
Fretlist draws it: bars, repeats, first and second endings, the % simile for "repeat the previous bar," strum-pattern rows, split bars, in your choice of a flat or a filled-panel look. It transposes with the song and reads big in Play Mode on stage. You can see it rendering on the homepage. If you work with instrumentals or jazz charts, the grid environment is the tier worth checking before you commit to any app.
Tier 5: chord definitions
The deepest part of the spec: ChordPro can define chord shapes, not just names, with {define}.
{define: Am7 base-fret 1 frets x 0 2 0 1 0}That is a full fingering. Handling it well means rendering it as an actual chord diagram, respecting {instrument: ukulele} for instruments with different shapes, and writing your custom voicings back out as {define} on export so they survive. Fretlist does this, wired into the whole app: tap a chord, flip through voicings, type your own fret notation, and the diagram follows the song's transpose and capo. I wrote about how Frets works when it shipped.
Where Fretlist still has gaps
I would rather tell you this than have you find it in an import. ChordPro has corners Fretlist does not fully handle yet:
- Embedded music notation. ChordPro can embed ABC and LilyPond scores between their own directives. Fretlist does not render these as a staff, and I will be straight about the part that stings: on import, those blocks are currently dropped. If your charts carry melody lines as embedded notation, that content does not come across today. It is the one place an import loses anything, and closing it is on the roadmap.
- Embedded images. The
{image}directive is not drawn yet, but unlike the notation blocks it is kept in the file, so it survives a round trip and export. - Custom fonts, sizes, and colors. Directives like
{textfont},{chordsize}, and{textcolour}are ignored on purpose. Fretlist applies its own consistent typography and theming across your whole library, which is usually what people want, but it does mean a file hand-styled with specific fonts and colors will look like Fretlist, not like the original. - Multi-column page layouts.
{columns}and{column_break}collapse to a single reflowing column that adapts to the screen you are on, rather than a fixed print-style multi-column page.
The thread through most of those: when Fretlist cannot render something, it preserves it rather than dropping it. Custom fonts, layout directives, the {image} tag, they all survive a round trip untouched. Embedded ABC and LilyPond notation is the honest exception, and I would rather you hear it from me than find it in an import. Everywhere else, your file comes out the other side whole, even the parts we do not draw yet.
Test any app in thirty seconds
You do not have to take my word for any of this, including the good parts. Copy the snippet below and paste it into any app that reads ChordPro, Fretlist included, and watch where each one stops:
{title: The Support Test} [Verse] [C]Every app can [G]render a plain [Am]line like [F]this {start_of_grid label="Outro" shape="1+4x2+1"} A |: C . | F G | Am7 F | Dm . :| Volta 1 |1 C7 . | C . :| Volta 2 |2 G7 . | C . | {end_of_grid} {start_of_grid shape="1+4x2+1"} | C . | F . | C . | G . | |s d dn~up | d dn~up | d dn~up | d u | {end_of_grid} {define: Cadd9 base-fret 1 frets x 3 2 0 3 0}
It is one ordinary line followed by four things apps quietly disagree on: a grid with a repeat and first and second endings, a strum-pattern row, and a chord definition. The first line renders everywhere. After that, watch closely. If the grid draws as a chart, the strum row shows arrows, and the {define} becomes a diagram, that app follows the format a long way up. If those come in as literal text, it covers the common subset, which may be all you need. Either answer is useful. The point is to know before you move your library, not after.
For the record, Fretlist draws every line of that snippet. That is the bar I hold it to.
Your chord sheets will outlive whichever app you use this year. That is the whole reason ChordPro exists as an open standard, and it is the standard Fretlist tries to honor as fully as it can, gaps and all.
Want to see where Fretlist lands? Try it free and bring your whole ChordPro library, grids, chord shapes, and all.