Important — v1.6 is a breaking change. BinaryFetch is receiving continuous updates, including architectural updates. Your old BinaryFetch config no longer works on v1.6. To make BinaryFetch 1.6 work properly, please delete this folder:

C:\Users\Public\BinaryFetch

BinaryFetch will recreate a fresh default config on the next launch. Because BinaryFetch is receiving continuous feature and architecture updates, your current config may no longer work in future versions either. Thank you for your support.

Every color used by BinaryFetch now comes from the top-level colors object in the config. No color name is hardcoded in the application logic anymore. You can define any color name you want, with no limit.

Three color formats are supported:

Example from the default config:

"colors": {
  "red":            "#F2726B",
  "green":          "#3ECF8E",
  "yellow":         "#F2C063",
  "blue":           "#60A5FA",
  "magenta":        "#C084FC",
  "cyan":           "#5EEAD4",
  "white":          "#E5E7EB",

  "bright_red":     "#F8A39D",
  "bright_green":   "#7EE2B8",
  "bright_yellow":  "#F6D68E",
  "bright_blue":    "#93C5FD",
  "bright_magenta": "#D8B4FE",
  "bright_cyan":    "#99F6E4",
  "bright_white":   "#F9FAFB",

  "reset":          "RESET",

  "purple":         "#A78BFA",
  "amber":          "#F2C063",
  "orange":         "#F2924B",
  "muted":          "#7D8491",
  "muted_2":        "107, 119, 122",
  "fg_dim":         "#C9CDD3"
}

How resolution works:

• Invalid color values are skipped. In debug builds, a warning is printed for each invalid entry.
• If the colors section is absent, BinaryFetch still runs. Every lookup degrades to plain white through a single hardcoded safety net.
• Because all modules read through the palette, changing one entry retints every element that references it.

BinaryFetch 1.6 supports two config extensions side by side:

• .jsonc — preferred going forward, parsed with comments allowed.
• .json — legacy, still parsed exactly as before. Comments are now allowed here too, but a comment-free file behaves identically either way, so nothing already deployed breaks.

Resolution order, checked fresh on every launch:

1. Both .jsonc and .json exist — .jsonc wins.
2. Only .jsonc exists — load it.
3. Only .json exists — load it as-is. BinaryFetch never silently creates a .jsonc next to it. An existing legacy install stays on .json until the user removes that file themselves.
4. Neither exists — self-heal from the embedded EXE resource. This is the only branch that ever creates a new file, and it always writes .jsonc.

So if you delete your .json later with no .jsonc present, BinaryFetch will recreate a fresh .jsonc default on the next run. Nothing ever overwrites a config file that already exists.

The technical change is ignore_comments = true in the JSON parser. A file with zero comments, which describes every existing .json config, parses byte-for-byte the same way as before. This is purely additive and requires no migration step for anyone already running BinaryFetch.

BinaryFetch 1.6 adds image support through the art section. Images are rendered using Sixel graphics, which Windows Terminal supports.

"art": {
    "Ascii_Art": {
        "enabled": true,
        "padding_up": 0,
        "padding_left": 0,
        "padding_right": 0
    },
    "Image": {
        "enabled": false,
        "image_path": "G:\\screenshot\\hisky.jpg",
        "image_size_percentage": 47,
        "padding_up": 1,
        "padding_left": 0,
        "padding_right": 1
    }
}

Notes on Windows paths:

• Windows paths need double backslashes \\ because a single backslash is a JSON escape character.
• Forward slashes / also work.
• Valid: "G:/screenshot/sky.jpg"
• Valid: "G:\\screenshot\\sky.jpg"
• Invalid: "G:\screenshot\sky.jpg"

You can toggle ASCII art and images independently. Padding is configurable on all sides. If your terminal does not support Sixel, the image will not render even if everything is configured correctly.

BinaryFetch 1.6 ships with a new default theme called Bitsmooth Lite. It is a softened, pastel version of the base palette, designed to be easier on the eyes during long terminal sessions.

The theme defines:

• Base colors: red, green, yellow, blue, magenta, cyan, white.
• Bright variants: bright_red, bright_green, bright_yellow, bright_blue, bright_magenta, bright_cyan, bright_white.
• Terminal-panel colors: purple, amber, orange, muted, muted_2, fg_dim.
• Reset: special RESET value.

All values are truecolor hex codes or plain RGB. You can replace any of them with your own values. Because every module reads colors through the config manager, changing the theme is a config-only operation.

BinaryFetch 1.6 introduces full ordering control. You can adjust the order of each core module, both compact and detailed. Everything is under your control.

The key is section_order at the top level of the config. It is an array of section names.

"section_order": [
  "header_settings",
  "compact_date_and_time",
  "compact_operating_system",
  "compact_processor",
  "compact_graphics_card",
  "compact_display_monitor",
  "compact_system_memory",
  "compact_audio_devices",
  "compact_resource_usage",
  "compact_user_account",
  "compact_network_connection",
  "compact_disk_storage",
  "detailed_resource_usage",
  //"detailed_system_memory",
  "detailed_disk_storage"
  //"detailed_operating_system",
  //"detailed_processor",
  //"detailed_graphics_card",
  //"detailed_display_monitor",
  //"detailed_bios_and_motherboard",
  //"detailed_user_account",
  //"detailed_network_connection",
  //"detailed_audio_and_power"
]

How to use it:

• Reorder entries to change the order modules appear.
• Comment out an entry to disable that whole section.
• Make sure to keep commas correct when commenting entries in or out.
• Non-string entries are silently skipped.
• If the array is empty or missing, BinaryFetch falls back to its built-in default layout.

BinaryFetch now supports UTF-8 format. This means you can use emoji everywhere in labels, prefixes, and strings, unless your terminal does not support it.

"emoji": {
  "enabled": false,
  "style": "color"
}

• enabled — when false, emoji-eligible glyphs and their variation selectors are removed entirely.
• style — accepts "auto", "color", or "text".
  • "auto" — pure no-op. The original string is returned untouched. This is what every config written before this feature existed will hit.
  • "text" — appends U+FE0E, the text presentation selector, to eligible glyphs.
  • "color" — appends U+FE0F, the emoji presentation selector, to eligible glyphs.

Note: the comment in the default config mentions "mono" for a guaranteed flat look, but the 1.6 validation only accepts "auto", "color", and "text". Any other value falls back to "auto" and prints a warning in debug builds.

Malformed or truncated UTF-8 sequences fall back to treating the single byte as-is, so a stray byte never corrupts or crashes the rest of the string.

The most important architectural addition in v1.6 is the expanded ConfigManager class, which now owns:

• Platform config loading (Dev, ReleaseSource, and user Public modes)
• JSON/JSONC resolution and self-healing
• Color palette parsing (parseColorValue, loadColorPalette, resolveColor)
• Emoji presentation (loadEmojiSettings, applyEmojiStyle)
• Section and subsection alias resolution
• Nested boolean, string, int, color, and string-array lookups
• Layout order through getLayoutOrder()

Every module now pulls its labels, prefixes, colors, and toggles through ConfigManager's public wrappers, so no module needs to know about JSON parsing, color formats, or emoji handling.

BinaryFetch still never breaks due to user mistakes (except JSON syntax errors). v1.6 adds:

• Invalid color values → skipped, falls back to safe defaults
• Invalid emoji style → falls back to "auto"
• Missing colors section → all lookups degrade to plain white
• Missing JSON/JSONC config → recreated from default schema
• Deleted directories → recreated silently

Hide a whole section (e.g. BIOS info):

"detailed_bios_and_motherboard": { "enabled": false }

Show clock speed before core count in the compact CPU line:

"compact_processor": { "order": ["clock", "cores_threads", "name"] }

Retheme everything from cyan to magenta: change the value of "cyan" under "colors" to whatever magenta hex or RGB you prefer. Because all modules read through the palette, one edit retints every cyan element at once.

Reorder your whole fetch screen (e.g. put GPU info right after CPU info): edit the "section_order" list near the top of the file and move "detailed_graphics_card" up next to "detailed_processor".

Show an image instead of ASCII art:

"art": {
  "Ascii_Art": { "enabled": false },
  "Image": {
    "enabled": true,
    "image_path": "C:/Users/Public/Pictures/banner.jpg",
    "image_size_percentage": 50
  }
}

Turn off all emoji and use plain text icons:

"emoji": { "enabled": false }

1. Delete C:\Users\Public\BinaryFetch before running BinaryFetch 1.6.
2. On the next launch, BinaryFetch will extract its embedded default config as BinaryFetch_Config.jsonc.
3. If you have a legacy BinaryFetch_Config.json and no .jsonc, BinaryFetch will still load it as-is. It will not be upgraded automatically. To use all 1.6 features, remove the old file and let BinaryFetch create a fresh .jsonc, or manually rename and update the file.
4. Because BinaryFetch is receiving continuous feature and architecture updates, current config may no longer work in future versions. Keep a backup of any customizations you make, and be prepared to reapply them after major updates.
5. For developers using ConfigMode::Dev or ConfigMode::ReleaseSource, the paths are:
   • src\BinaryFetch\resources\Dev_jsonc\Dev_BinaryFetch_Config.jsonc
   • src\BinaryFetch\resources\Default_JSON_theme_windows_RC\Default_BinaryFetch_Config.jsonc

Q: Does Binary Fetch share user data? A: No. Binary Fetch does not collect or share any user data.

Q: Does Binary Fetch run in the background? A: No. Binary Fetch is a CLI tool and only runs when the command is executed in the terminal.