The marker symbol survives a KML round trip, as a picture
Short answer: the symbol is still there after you export and re-open the file — the artwork travels in both arms, Export KML and Export KMZ — but it comes back as an image rather than a symbol, so the Marker colour control has nothing left to act on. The viewer says so before you export; this post is what that means in the bytes.
Tested on 1 October 2026 in the KMZ viewer, with the downloaded files as the evidence rather than the screen. The fixture: five placemarks, three of them drawn with a catalogue symbol over two distinct artworks.
The notice you get before you export
Load a file with at least one symbol-drawn point and a line appears under the map: KML now keeps the marker symbol too, as an embedded image — it can't be recoloured as a symbol again after re-import.
It is conditional: the notice renders only while something in the file carries a catalogue symbol. Two plain points never produce it; a styled line and polygon with no point icon do not either, though that fixture does still show the CSV and WKT warning. Its absence means there is no symbol to warn about, not that the export keeps everything.
What travels: Export KMZ
unzip -l on the download lists four entries: a directory entry icons/, then icons/4d5fba0a4a4db68a.png at 885 bytes, icons/e5c50b2e7afaf1da.png at 1,452 bytes, and doc.kml at 1,655 bytes. Both image entries are real PNGs, magic number 89504e470d0a1a0a.
Three placemarks carried a symbol over two distinct artworks, and the archive holds exactly two PNGs: the pair sharing one artwork share one file. The entry name is a hash of the image, so the archive is keyed by the picture, not by the placemark. Inside doc.kml, three <IconStyle> blocks point at those two files by relative path — the first name twice, the second once — and no <Icon><href> holds an inline image.
What does not travel is the symbol's identity: doc.kml carries no gdSymbol and no <ExtendedData>, so the name Hospital is nowhere in it. One caution: two exports of the same layer are not the same file, because each entry is stamped with the clock at the moment you click. Compare the entries, never the archives.
What travels: Export KML
A plain KML has no container to put a PNG in, so it inlines it. Each of the three <IconStyle> hrefs begins data:image/png;base64, — two distinct values, the same three-into-two collapse as the KMZ. Decode them and you get the same two PNGs the KMZ carries as files, at the same two sizes. One rasteriser, two containers: the KMZ gets a file because it can, the KML gets a data: URI because it cannot. So "KML or KMZ" is not the decision here — both carry the picture, neither carries the symbol.
Why it cannot be recoloured
Drop either export back in, select the first point, and the Styles panel tells you what you have. The Marker symbol picker, which read Hospital before the export, now reads File icon. The Clear symbol button, which exists only while a catalogue symbol is set, is gone. And Marker colour is still drawn and does nothing: the control is there and its checkbox is disabled. It is present and inert rather than missing.
The reason is in the file rather than the interface. A catalogue symbol is a name, and a name can be re-drawn at any colour you ask for; an embedded PNG is pixels that already have one. Coming back in there is no symbol identifier for a colour control to act on, so the panel simply shows you the artwork, as a small data:image/png;base64, preview beside the picker.
The notice disappears on re-import, which is the same fact from the other side: with no catalogue symbol left, there is nothing to warn about. The picture keeps going, though — export KMZ again from the re-imported KMZ and the two image entries come back with the same payloads and still no gdSymbol. It never turns back into a symbol.
The boundary: a GDAL round trip is a different question
Do not read that as "KML round trips keep styles" — it is this viewer's export specifically. Our KML and KMZ guide, in its "Errors, decoded" section, sends a KML holding two <Style> blocks and a <StyleMap> through GeoJSON with ogr2ogr and back, and reports grep -c '<Style' roundtrip.kml printing 0. That number is the guide's, measured on a GDAL round trip, not ours. Run the same conversion on this post's fixture and GDAL answers 2 instead — but both survivors are its own default red outline with no fill, not the input's colours, so the guide's conclusion holds and only its count is fixture-specific. GDAL does not carry your styles across; it re-synthesises defaults on the way out, and the symbol is gone the moment GeoJSON is reached.
The viewer's export answers the same-sounding question differently: the styles come through, and the symbol comes through as artwork. To count that yourself use grep -o '<Style' | wc -l, which gives 5 on the export above. An export from here is one long line, so grep -c '<Style' answers 1 however many styles are inside. The guide's "The structure that matters" section has the aabbggrr colour order if you read the hex by hand.
What to do about it
- Keep a styled master in KML and treat every export as output. Re-export when the styling changes, rather than editing an export and sending it back upstream.
- Re-apply the symbol after import. The artwork is still a usable
File icon, and picking a catalogue symbol again fromChoose symbolgives back a recolourable marker. - Decide which you need. If the point only has to look like a hospital on someone else's screen, the embedded image does that in both arms.
Test files you can use
Nothing is hosted; the fixture is a few lines you paste into a UTF-8 symbols.kml. Open with <?xml version="1.0" encoding="UTF-8"?>, then <kml xmlns="http://www.opengis.net/kml/2.2"><Document><name>Symbol test</name>, the placemarks, then </Document></kml>. A catalogue symbol rides in extended data, so each symbol-drawn point needs one <ExtendedData><Data name="gdSymbol"><value>hospital</value></Data></ExtendedData> block. Coordinates are decimal degrees on purpose.
<Placemark><name>H1</name><ExtendedData><Data name="gdSymbol"><value>hospital</value></Data></ExtendedData><Point><coordinates>-46.633,-23.550,0</coordinates></Point></Placemark><Placemark><name>H2</name><ExtendedData><Data name="gdSymbol"><value>hospital</value></Data></ExtendedData><Point><coordinates>-46.631,-23.548,0</coordinates></Point></Placemark><Placemark><name>A1</name><ExtendedData><Data name="gdSymbol"><value>airport</value></Data></ExtendedData><Point><coordinates>-46.656,-23.627,0</coordinates></Point></Placemark>
Two points on one symbol and one on another is what makes the shared entry visible. Drop it on the viewer and check the notice renders before exporting — if it does not, nothing carries a symbol and there is nothing to embed. Then unzip -l geodocs-export.kmz should list one icons/ entry per distinct artwork: two, not three.
For teams
Styling points by hand does not survive a handover: whoever picked the symbols has the master, everyone else has an export, and an export is a picture. Geodocs keeps the symbol as a symbol, because the data lives on a shared map instead of in a file going round by email, so there is no round trip to survive.