What is the O file format?
A .o file is a compiled object file - an intermediate binary produced by a compiler such as GCC or Clang when it translates a single C source file into machine code. The output contains machine instructions, initialized and uninitialized data segments, a symbol table, and relocation entries, but it is not yet executable: references to functions and variables defined in other translation units are left as unresolved placeholders for the linker.
The binary format depends on the target platform:
- On Linux and most Unix/BSD systems,
.ofiles use the ELF (Executable and Linkable Format) container, recognized by the magic bytes\x7FELFat byte offset 0 and ane_typeofET_REL(relocatable, value0x0001). - On macOS, the equivalent uses the Mach-O format, beginning with
CF FA ED FE(64-bit little-endian). - On Windows the functionally identical file is named with the .obj extension and uses the COFF format.
After compilation, the linker (ld) combines one or more .o files with libraries to produce an executable or a shared library. Multiple .o files can also be bundled into a static archive using the ar command.
.o files are temporary build artifacts generated automatically by the toolchain and are not intended to be opened by end users. Developers who need to inspect them can use nm, objdump, or readelf to examine symbols, sections, and disassembly.
Security & safety
RISK: LOWA .o is build-time data, not something the OS launches, so it poses little direct risk to end users - you cannot double-click and run it. For developers the concern is supply-chain trust: linking an object from an untrusted source bakes its machine code straight into your program, so only build with objects/libraries from sources you trust. The objects in your own build tree are safe to delete; they regenerate on the next compile.
Format details
in a nutshellFULL NAMECompiled Object Fileaka object file, object code
DEVELOPERUnix lineage; ELF defined by System V ABI / Tool Interface Standard, COFF/Mach-O by Microsoft/Apple. No single vendor.since Object-file concept from early Unix (1970s); ELF since System V Release 4 (early 1990s)
CATEGORYDeveloper Files
MIME TYPEapplication/x-object
TYPECompiled relocatable object file (machine code + symbols, not yet linked)
STANDARDOpen · royalty-free
MAGIC BYTES · FILE SIGNATURE
OFFSET
00010203
HEX
7F454C46
ASCII
·ELF
The .o extension is a role, not a single byte format. On Linux/Unix a .o is an ELF object beginning with 7F 45 4C 46 ("\x7FELF") with e_type = ET_REL (0x0001, relocatable). On macOS a .o is Mach-O, starting CF FA ED FE (64-bit LE) or FE ED FA CF (big-endian). Windows COFF .obj objects have no fixed leading magic (machine field, e.g. 64 86 for x86-64, near the start). Identify by the platform's object container, not one universal signature.
Programs that open O files
Windows2 apps
Microsoft Visual Studio
Freemium MSVC uses COFF .obj, not Unix .o. A Unix .o only builds on Windows via WSL/MinGW with a matching toolchain - it is not a native opener. 
MinGW-w64 / WSL (gcc, binutils)
Open-source Provides gcc/clang + binutils on Windows so you can link and inspect Unix-style .o files. 
macOS2 apps
Apple Xcode / Clang
Free Xcode's clang builds and links Mach-O .o files. Inspect with 'nm'/'otool -tv file.o' (install via 'xcode-select --install').
GCC (Homebrew)
Open-source Alternative compiler to build/link .o files; emits Mach-O objects on macOS. 
Linux3 apps
GCC / Clang (linker)
Open-source You don't open a .o - you link it: 'gcc a.o b.o -o app' produces the executable. Compile a single object with 'gcc -c file.c'.
binutils (nm / objdump / readelf)
Open-source 'nm file.o' lists symbols; 'objdump -d file.o' disassembles; 'readelf -a file.o' shows the full ELF structure.
Ghidra
Open-source Import the .o for full disassembly/decompilation when reverse-engineering compiled code. Technical details
deep spec| Container format | ELF on Linux/Unix, Mach-O on macOS, COFF on Windows (where the file is typically named `.obj`) |
| File encoding | Binary (not human-readable text) |
| ELF magic bytes | `7F 45 4C 46` (`\x7FELF`) at byte offset 0 - present in all ELF-based object files |
| ELF object type field | `e_type = ET_REL` (0x0001) in the ELF header - distinguishes a relocatable object from an executable (`ET_EXEC`) or shared library (`ET_DYN`) |
| MIME type | `application/x-object`; also carried as `application/octet-stream` by generic servers |
| Byte order | Encoded in the `EI_DATA` byte of the ELF header: little-endian (`ELFDATA2LSB`) on x86/x86-64/ARM, big-endian (`ELFDATA2MSB`) on PowerPC/SPARC |
| Key sections | `.text` (executable code), `.data` (initialized globals), `.bss` (zero-initialized globals), `.rodata` (read-only constants) |
| Symbol table | `.symtab` section lists each defined and referenced symbol's name, binding (local/global/weak), type (function/object), and value |
| Relocation entries | `.rel.text` / `.rela.text` sections record every address slot the linker must patch when merging object files into a final binary |
| Architecture identification | `e_machine` field in the ELF header identifies the CPU target: `EM_X86_64` (0x3E), `EM_AARCH64` (0xB7), `EM_386` (0x03), etc. |
| Typical file size | 1 KB to several MB per translation unit, depending on source complexity and compiler optimization level |
| Compression | None - object files are stored as raw uncompressed binary data |
| One-to-one compilation model | Exactly one `.o` file is emitted per source translation unit (one per `.c` or `.cpp` file); the linker later merges them |
| Static library packaging | Multiple `.o` files are archived into a `.a` static library using `ar`, which preserves each object as a named member |
| Link-time resolution only | Unlike `.so` / `.dylib` shared libraries, all symbol references in a `.o` are resolved entirely at link time, leaving no runtime dynamic dependencies |
| Inspection tools | `nm` (list symbols), `objdump` (disassembly and section dumps), `readelf` (ELF header and section details), `otool` (macOS Mach-O equivalent) |
| Released | Object-file concept from early Unix (1970s); ELF since System V Release 4 (early 1990s) |
| Latest version | ELF format frozen since the 1990s; container evolves with each compiler/ABI |
| Open standard | Yes · royalty-free |
| Specification | refspecs.linuxfoundation.org |
O conversions
Possible
.O .EXEGUIDE
Yes - link your .o files with GCC or Clang using a single command: gcc *.o -o app
How to convert
.O .AGUIDE
Yes, you can bundle .o files into a .a static library with one ar command - no binary transformation happens,…
How to convert
.O .SOGUIDE
You can produce a .so from .o files by linking with GCC or Clang, but only if the objects were compiled with…
How to convert
Not possible
Community Q&A
asked by usersNo questions yet - be the first to ask about O files.
Frequently asked questions
What is a .o file?
A compiled object file - the machine-code output a compiler produces for one source file before linking. The linker combines several .o files (plus libraries) into a finished executable or library. On Windows the same role uses the .obj extension.
How do I open a .o file?
You don't open it like a document - it's consumed by the linker during a build. To inspect it, run 'nm file.o' (symbols), 'objdump -d file.o' (disassembly) or 'readelf -a file.o' (ELF details) on Linux/macOS.
Can I delete .o files?
Yes - object files are intermediate build artefacts. Deleting them (or running 'make clean') just means the compiler regenerates them on the next build. Don't delete them mid-build.
What's the difference between .o, .a and .so?
A .o is a single compiled object. A .a is a static library - an archive of .o files copied into your program at link time. A .so is a shared library loaded at run time. All three are built from the same objects.
Is a .o the same as a Windows .obj?
Same role (a compiled object), different container: Unix .o is ELF/Mach-O, Windows .obj is COFF. They are not interchangeable - recompile the source for the target platform.
Why do I get 'undefined reference' linking my .o files?
A symbol (function/variable) your object uses isn't defined in any .o or library you're linking. Add the missing object/library to the link command, or define the symbol. 'multiple definition' is the opposite - the same symbol in two objects.
References
1GNU Binutils - nm/objdump/readelf documentationwww.gnu.org
2Wikipedia - Object fileen.wikipedia.org
