[GH-ISSUE #1236] Mexico and Spain flags are extremely detailed and large in file size #571

New issue

Closed

opened 2026-03-03 14:39:26 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 14:39:26 +03:00

Owner

Originally created by @magwo on GitHub (Apr 29, 2024).
Original GitHub issue: https://github.com/lipis/flag-icons/issues/1236

Hello!

Thanks for an amazing library.

Considering this repository is called flag-icons, one might assume that most consumers use the flags as icons, which means pretty small on-screen sizes. Probably around 30x30 pixels or similar, usually. So miniscule details are probably not required or desired.

I think it's ok that some obscure, uncommon flags are large in filesize, as they are probably infrequently used. But some common flags are quite heavy in filesize - most notably Mexico and Spain (89 KB and 93 KB).

This is because they are extremely detailed in some decorative elements. Having lots of tiny details not only increases file size, but also the CPU load of parsing and drawing the SVG.

Proposed solutions

Merging many small paths into big paths

SVGO has a plugin for that. But studying the plugin code I've found that it requires that path elements come after each other and have exactly the same attributes.
I think some of the large flags do have many elements with matching attributes, but have alternating fill and stroke paths, causing them to be non-mergeable. This might be a reason SVGO compression doesn't work as well as it could.

If one could sort the fill/stroke/stroke-width elements so that they are grouped together, SVGO optimizations might give good results.

Removing superflous elements

Removing superflous elements that are practically invisibile at sub-100px size. This could be tricky at times because sometimes very small individual paths together make up a big important part of the flag. Therefore one might want to merge paths before deciding which paths are superflous.

Reduce path complexity

Reducing path complexity by using simplify-svg-path or similar tools. I tried this and there were issues with paths that have more than one Move command. The path simplifier can't handle moves beyond the first one causing lines to be drawn between segments.

Approximate major graphical elements

Manually extract certain graphical elements and run them through some sort of approximator tool that generates a path that outlines the entire shape. For example a big detailed eagle might become a single, quite simple path that still looks very much like a nice eagle at sub-100px sizes.

Screenshots showing many alternating strokes/fills (Spain flag):

Originally created by @magwo on GitHub (Apr 29, 2024). Original GitHub issue: https://github.com/lipis/flag-icons/issues/1236 Hello! Thanks for an amazing library. Considering this repository is called flag-icons, one might assume that most consumers use the flags as icons, which means pretty small on-screen sizes. Probably around 30x30 pixels or similar, usually. So miniscule details are probably not required or desired. I think it's ok that some obscure, uncommon flags are large in filesize, as they are probably infrequently used. But some common flags are quite heavy in filesize - most notably Mexico and Spain (89 KB and 93 KB). This is because they are extremely detailed in some decorative elements. Having lots of tiny details not only increases file size, but also the CPU load of parsing and drawing the SVG. ## Proposed solutions ### Merging many small paths into big paths SVGO has a plugin for that. But studying the plugin code I've found that it requires that path elements come after each other and have exactly the same attributes. I think some of the large flags do have many elements with matching attributes, but have alternating fill and stroke paths, causing them to be non-mergeable. This might be a reason SVGO compression doesn't work as well as it could. If one could sort the fill/stroke/stroke-width elements so that they are grouped together, SVGO optimizations might give good results. ### Removing superflous elements Removing superflous elements that are practically invisibile at sub-100px size. This could be tricky at times because sometimes very small individual paths together make up a big important part of the flag. Therefore one might want to merge paths before deciding which paths are superflous. ### Reduce path complexity Reducing path complexity by using [simplify-svg-path](https://github.com/luncheon/simplify-svg-path) or similar tools. I tried this and there were issues with paths that have more than one Move command. The path simplifier can't handle moves beyond the first one causing lines to be drawn between segments. ### Approximate major graphical elements Manually extract certain graphical elements and run them through some sort of approximator tool that generates a path that outlines the entire shape. For example a big detailed eagle might become a single, quite simple path that still looks very much like a nice eagle at sub-100px sizes. ## Screenshots showing many alternating strokes/fills (Spain flag): <img width="893" alt="Screenshot 2024-04-29 at 14 03 42" src="https://github.com/lipis/flag-icons/assets/548345/b7b61d5f-4f55-4bce-8b58-0dd6dd6910bc"> <img width="943" alt="Screenshot 2024-04-29 at 14 03 52" src="https://github.com/lipis/flag-icons/assets/548345/6d44fb7c-31e0-4924-93cf-e8fb05f08b79"> <img width="1042" alt="Screenshot 2024-04-29 at 14 04 04" src="https://github.com/lipis/flag-icons/assets/548345/cf505ecd-febb-4c85-8135-2bf55d8573e7">

kerem

2026-03-03 14:39:26 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 14:39:27 +03:00

Author

Owner

@NotTsunami commented on GitHub (May 9, 2024):

While it is true a lot of users use them in resolutions smaller than 100x100, there are users at higher resolutions, and these are intentionally designed as SVGs to support multiple resolutions. There was a point in time where I was going through the largest flags and attempting to optimize where possible, but I haven't had the bandwidth to continue that endeavor recently. Unfortunately, one of the larger optimizations that we tried a while back caused issues when used in React Native.

@NotTsunami commented on GitHub (May 9, 2024): While it is true a lot of users use them in resolutions smaller than 100x100, there are users at higher resolutions, and these are intentionally designed as SVGs to support multiple resolutions. There was a point in time where I was going through the largest flags and attempting to optimize where possible, but I haven't had the bandwidth to continue that endeavor recently. Unfortunately, one of the larger optimizations that we tried a while back [caused issues](https://github.com/lipis/flag-icons/issues/1127) when used in React Native.

kerem commented

2026-03-03 14:39:27 +03:00

Author

Owner

@lipis commented on GitHub (May 21, 2024):

These are SVG flags and as close to official as possible..! If size matter in your case convert them to small pngs or something.. but we won't alter the flags just because of the size..! We are relying on SVGO to make them smaller, but that's it..

@lipis commented on GitHub (May 21, 2024): These are SVG flags and as close to official as possible..! If size matter in your case convert them to small pngs or something.. but we won't alter the flags just because of the size..! We are relying on SVGO to make them smaller, but that's it..

kerem referenced this issue

2026-03-03 14:41:07 +03:00

[PR #571] [MERGED] Bump husky from 2.4.1 to 2.5.0 #868