Album art not showing on Windows, iPhone, Android or in the car: every cause, in order
You embedded the cover. The editor's preview shows it. The player shows a grey square. This is the most common email I get, and the answer is almost never "the tag is wrong". Here are the causes in the order I'd check them, from most likely to least.
First, confirm what's in the file
Drop the file into the editor. If the preview shows the cover, the picture is in the tag and the problem is on the player's side. If the preview shows "No art", the image never made it in, usually because you edited a copy and are playing the original, or because a player "removed" it when it re-saved the file. Fix that first; the rest of this page assumes the art is really there.
1. The player is showing its cache
Music apps read a file once, when it's added, and store what they found in their own database. From then on they show you the database, not the file. Replace the file with a re-tagged copy of the same name and the app cheerfully keeps showing the old cover, because as far as it knows nothing changed.
The fix is to make the app look again. In Apple Music or iTunes, delete the track from the library (keep the file), then add the new file. Windows Media Player: same idea, remove and re-add, or let it rescan the folder. On Android, players use the system's media database; a "rescan library" option in the app, or clearing the app's cache from Settings, forces a fresh read. On an iPhone, files synced through Apple Music need re-syncing after they change; files in a third-party player app need re-importing.
2. Windows Explorer's thumbnail cache
Explorer keeps its own cache of file thumbnails, separate from any music app. Change the cover inside a file and Explorer may show the old thumbnail for days. Run Disk Cleanup, tick Thumbnails, and let it clear them, or rename the file, which gives it a new cache entry. This one catches people who've already cleared the music app's cache and can't understand why the folder view disagrees.
3. The device only reads ID3v1
Old car head units, cheap USB players and some clock radios read only the 128-byte ID3v1 block at the end of the file. That block has no room for a picture; it was designed for 30-character titles in 1996. If the device shows titles but never a cover for any file, this is why, and no tag will fix it. What ID3v1 looks like.
4. The tag version
Some devices, and some older Windows software, read ID3v2.3 but not 2.4 or 2.2. If the cover shows on your computer and not in the car, and the car does show covers for other files, check what version those other files have. Re-saving with a tool that writes 2.3, which is what this editor and most desktop taggers do by default, fixes it.
5. The image itself
A JPEG can be baseline or progressive, and can be RGB or CMYK. Baseline RGB is what everything decodes. Progressive JPEGs (common from web downloads and some photo apps) and CMYK JPEGs (from print artwork) are refused by some older devices, which then show nothing rather than an error. Very large images can also be refused, or slow the device to a crawl while it decodes them for a thumbnail. Re-save the picture as a plain JPEG at 600 to 1000 pixels and embed that. The size guide has measured numbers.
6. The picture is in the folder, not the file
Windows Media Player and some desktop players will show a folder.jpg or cover.jpg sitting next to the MP3s, without anything embedded. That looks like "the art works" until you copy the files to a phone or a USB stick, where the folder image isn't consulted. Embed the art in every file and it travels with them.
7. Wrong picture type
An ID3v2 tag can hold several pictures, each labelled with a type: front cover, back cover, artist photo, and so on. Most players show the one marked front cover (type 3) and ignore the rest. A tagger that embedded the image as "other" (type 0) produces a file where the art is present but invisible in some players. The editor here always writes type 3. A desktop tagger will show you the type of each embedded picture if you need to check.
Why every file needs its own copy
People sometimes embed the cover in track 1 only and expect the album to pick it up. Players don't work that way; each file is read on its own, and a file without art shows without art. Yes, this means an album carries twelve copies of the same picture. At 40 to 80 KB each that's under a megabyte per album, which is a fair price for art that works everywhere.
The quick version
| What you see | Likely cause | Fix |
|---|---|---|
| Old cover still shows after re-tagging | Player cache | Remove and re-add the track |
| Folder thumbnail wrong in Explorer | Thumbnail cache | Disk Cleanup → Thumbnails |
| No covers for any file on one device | Reads ID3v1 only | Nothing; the device can't |
| Covers work for some files, not others | Tag version or image format | Re-save as ID3v2.3 with a baseline JPEG |
| Works on PC, not on phone or USB | folder.jpg, nothing embedded | Embed in each file |
| Art visible in one app, missing in another | Picture type isn't front cover | Re-embed as front cover |