Pascal VOC vs YOLO: Choosing an Annotation Format (and Switching Anytime)

Every annotation session ends in the same question: which format does your training pipeline want? The two dominant answers for detection are Pascal VOC XML and YOLO txt. They describe the same boxes with different conventions, and choosing wrong is not a disaster — as long as your annotation tool can switch without making you re-label.

File layout

	Pascal VOC XML	YOLO txt
Storage	One <image>.xml next to each image	One <image>.txt next to each image (plus one classes.txt)
Coordinates	Absolute pixels: xmin, ymin, xmax, ymax	Normalized 0–1: class x_center y_center width height
Class mapping	Class name written per object	Class index into classes.txt — order matters!
Metadata	Rich: folder, filename, size, database, source	Minimal: just the boxes
Polygons	Not in the classic schema (usually custom tags)	YOLO-seg style: variable-length point list per line
Typical consumer	Classic detectors, MMDetection, research code	Ultralytics YOLO family, darknet, most production pipelines

The same box, both ways

A 640×480 image with one "person" box from (100, 60) to (300, 420):

VOC XML (absolute pixels, human-readable):

<bndbox>
  <xmin>100</xmin>   <ymin>60</ymin>
  <xmax>300</xmax>   <ymax>420</ymax>
</bndbox>

YOLO txt (normalized, center-based):

0 0.3125 0.5000 0.3125 0.7500

The YOLO line reads: class 0, center at (0.3125, 0.5), size (0.3125, 0.75) — all fractions of image width/height. Because coordinates are normalized, the same txt file is valid if you resize the image (as long as the aspect ratio holds), which is exactly what training pipelines like.

How to choose

• Training YOLO-family models? YOLO txt, obviously — no converter step, no class-name drift.
• Working with classic detectors or MMDetection configs? VOC XML.
• Mixed or uncertain? Label in one format, export both. The boxes are identical; conversion is lossless for rectangles.
• Polygons / segmentation-style labels? Make sure your tool writes them explicitly (YOLO-seg style point lists). Plain VOC XML has no polygon object in the classic schema.

Two practical warnings. First, YOLO's classes.txt is positional: inserting a new class in the middle silently re-numbers every existing label — append new classes at the end, always. Second, VOC XML records pixel coordinates; if you ever resize images after labeling, the XML must be scaled too. Normalized YOLO files are immune to uniform resizing, which is one reason they became the default.

What to expect from your annotation tool

The format decision should be a project setting, not a life decision. FlyLabelImg stores annotations as sidecar files next to your images — .xml or .txt depending on the project switch — so the dataset is portable without any export step, and you can flip a project between VOC and YOLO without touching the labels. Polygons are written as YOLO-seg style lines when the project is in YOLO mode.

FAQ

Can I convert VOC XML to YOLO without losing anything?

For rectangles, yes — the conversion is arithmetic. For polygons and unusual attributes, only what both schemas can express survives; that is why labeling in a tool that writes both formats natively avoids the round-trip entirely.

Which format is faster to load in training?

YOLO txt is smaller and trivially parsed; VOC XML carries more metadata but costs more to parse. At dataset scale, both are negligible next to image decoding.

My classes.txt order changed and labels look wrong — what happened?

Class indices are positional in YOLO format. Restore the original class order in classes.txt and the labels resolve correctly again; going forward, append new classes at the end.