UF2 HEX
File conversion

Convert UF2 to HEX

Convert now
QUICK ANSWER
Is it possible to convert UF2 to HEX?
Yes - UF2 converts to HEX.

You can do it right here with our free converter - no sign-up, and your file is deleted right after.

uf2conv.py only outputs .bin (and C arrays), not Intel HEX, so do it in two steps: uf2conv.py firmware.uf2 -c -o firmware.bin, then objcopy -I binary -O ihex --change-addresses 0x<base> firmware.bin firmware.hex. The base address matters - a raw .bin has no address info, so you must re-supply the flash offset or the HEX records will start at 0.

Also to HEX: WXB · S19 · INO

On this page

Tested on macOS, Windows & Linux
Last verified Sep 2026

More free converters

HEIC, PNG, WEBP, MP3 and more - every tool here is free.

Open the toolbox
UF2 → HEX converterFREE
Drop a .UF2 file here
or pick one - we convert it to .HEX and give you the file to download

Why convert UF2 to HEX?

UF2 wraps firmware for drag-and-drop flashing, while .hex (Intel HEX) is an ASCII format that encodes both the data and its memory addresses, used by many flashers and programmers. Since uf2conv.py doesn't emit Intel HEX, you route through a raw .bin and let objcopy (from GNU binutils) add the address records. This is common when a target's programmer or bootloader expects .hex rather than UF2.

How to convert UF2 to HEX

uf2conv.py then objcopy OPEN-SOURCE

Run uf2conv.py firmware.uf2 -c -o firmware.bin, then objcopy -I binary -O ihex --change-addresses 0x2000 firmware.bin firmware.hex to add the flash offset.

objcopy (GNU binutils / arm-none-eabi) FREE

Use the toolchain's arm-none-eabi-objcopy -I binary -O ihex firmware.bin firmware.hex. Add --change-addresses to place the data at the right memory address.

SRecord (srec_cat) OPEN-SOURCE

If objcopy's offset handling misbehaves, run srec_cat firmware.bin -binary -offset 0x2000 -o firmware.hex -intel to build the Intel HEX with a precise address.

About these formats

Quality & what to watch

  • There is no one-command UF2-to-HEX; the raw .bin in the middle loses the address, so you must re-supply the flash base offset in the objcopy/srec step.
  • Get the offset wrong and the .hex will place code at the wrong memory address, which can brick or fail to boot the device.
  • Some objcopy versions had regressions converting binary to ihex; SRecord is the recommended fallback for exact offsets.

Frequently asked questions

Why two steps?
uf2conv.py only outputs raw .bin and C arrays, not Intel HEX. You convert UF2 to .bin, then use objcopy or SRecord to make the .hex.
What offset do I use?
Use the flash base address the firmware is meant to run at (often the app region past the bootloader). Pass it via --change-addresses or srec -offset.
Where do I get objcopy?
It ships with GNU binutils; for ARM MCUs use the arm-none-eabi-objcopy from the GNU Arm Embedded toolchain.
What if objcopy gives wrong addresses?
Use SRecord's srec_cat with an explicit -offset, which handles binary-to-Intel-HEX address placement reliably.