COCO vs Pascal VOC vs YOLO: Annotation Export Formats Explained (2026)

Quick Answer: Which Annotation Export Format Should You Use?

Use YOLO TXT for any Ultralytics YOLO model (YOLOv5 through YOLO26). Use COCO JSON for Detectron2, MMDetection, or any research framework using the COCO evaluation protocol. Use Pascal VOC XML only for annotation inspection and QA review, or when a legacy tool requires it. If the target framework is not yet finalized, COCO JSON is the safest default because it is convertible to both other formats with established tooling.

Why Annotation Export Format Is an Engineering Decision, Not a Preference

Annotation format is often treated as an administrative detail handled at export time by whichever tool produced the labels. That framing understates the consequences. The format determines the structure of the annotation files, the coordinate system used to encode object locations, the number of files generated per image, and the range of annotation types the format can represent.

Three Structural Differences That Account for Most Conversion Errors

The first structural difference is the coordinate system. Pascal VOC uses absolute pixel coordinates in XYXY format. COCO uses absolute pixel coordinates in XYWH format. YOLO uses normalized coordinates in center XYWH format. A bounding box at pixel position (100, 200) with width 50 and height 80 is encoded completely differently in each format, and converting between them requires knowing the image dimensions.The second structural difference is the file structure. Pascal VOC creates one XML file per image. COCO stores all annotations for a dataset in a single JSON file. YOLO creates one TXT file per image. A framework that expects one file per image will not process a single COCO JSON correctly without an adapter layer.The third structural difference is the class ID convention. COCO category IDs are not guaranteed to be zero-indexed; in the standard COCO dataset they begin at 1. YOLO requires zero-indexed class IDs. This mismatch is a common source of class misalignment when converting between the two formats, producing a model that predicts every class one position offset from the ground truth.

COCO JSON: Structure, Coordinate System, and Supported Tasks

The COCO format takes its name from the Microsoft Common Objects in Context dataset, released in 2015. The dataset contains over 330,000 images annotated across 80 object categories and established the JSON-based annotation format that has since become the dominant standard for research and production computer vision.

File Structure

COCO stores all annotations for a dataset in a single JSON file. That file contains five top-level sections: info (general dataset metadata), licenses (image license information), images (a list of all images with their IDs, filenames, width, and height), annotations (a list of all annotation objects across all images), and categories (the class taxonomy with category IDs and names).Each annotation object in the annotations list contains: id (a unique annotation identifier), image_id (linking the annotation to its image), category_id (linking to the categories list), bbox (the bounding box in [x, y, width, height] format where x and y are the top-left corner coordinates), area (the annotation area in pixels), iscrowd (indicating crowd encoding as RLE mask vs single object polygon), and optionally segmentation (polygon vertices or RLE-encoded mask).

Coordinate System

COCO bounding boxes use absolute pixel coordinates in XYWH format: the x and y values locate the top-left corner of the bounding box in pixels, and width and height are also expressed in pixels. These are not normalized values. The coordinates depend on the actual pixel dimensions of the image, which means annotation files are only valid for images at the dimensions specified in the images section of the JSON.

Supported Annotation Types and Framework Compatibility

COCO supports bounding box detection, instance segmentation (polygon or RLE mask), keypoint detection, and image captioning within the same format structure. This multi-task support is one of the primary reasons COCO has become the dominant research format: a single dataset file can serve multiple model types simultaneously.COCO JSON is natively supported by Detectron2, MMDetection, TensorFlow Object Detection API, and most major segmentation and detection training frameworks. Detectron2 registers datasets using register_coco_instances(), which expects a COCO-format JSON annotation file. MMDetection recommends converting custom datasets to COCO format as the primary path to training. When in doubt about which format to export, COCO JSON is the safest default for research pipelines, multi-task datasets, and any workflow involving segmentation or keypoints.

Practical Limitation at Scale

The single-file structure of COCO is convenient for dataset management but becomes unwieldy at scale. A COCO JSON file for a large dataset with tens of millions of annotations is a very large JSON object that requires significant memory to load and parse. For training pipelines that process annotations incrementally, the single-file structure requires loading the entire annotation dataset into memory before training can begin.

Pascal VOC XML: Structure, Coordinate System, and Current Role in 2026

Pascal VOC takes its name from the PASCAL Visual Object Classes challenge, which ran annually from 2005 to 2012 and produced one of the first standardized object detection benchmarks. The challenge dataset contains approximately 20,000 annotated images across 20 object categories. The XML-based annotation format introduced by the challenge has remained in use as an interchange format, though its role in production pipelines has narrowed considerably since COCO and YOLO formats became dominant.

File Structure and Coordinate System

Pascal VOC creates one XML file per image. The filename matches the image filename with an .xml extension. Each XML file is self-contained and includes the image filename, the image dimensions (width, height, and depth), and one object block for each annotated object in the image. Each object block contains the class name and the bounding box coordinates.Pascal VOC bounding boxes use absolute pixel coordinates in XYXY format: xmin and ymin locate the top-left corner of the bounding box, and xmax and ymax locate the bottom-right corner. All four values are in absolute pixels, not normalized. This XYXY convention differs from COCO's XYWH convention and from YOLO's normalized center XYWH convention, which means any conversion between formats requires explicit coordinate transformation.

The Human Readability Advantage

Pascal VOC XML files are human readable in a way that JSON and plain-text TXT files are not. The hierarchical XML structure makes it straightforward to inspect an annotation file manually and verify that the labels are correct. This readability makes Pascal VOC a useful format for annotation QA workflows and for tools that need to display annotation metadata to non-technical reviewers.

The Model Compatibility Problem

Pascal VOC is a common XML annotation format that is human readable but does not work with any known object detection model natively. Faster R-CNN, YOLO, and other production architectures require conversion from VOC XML to their native format before training. This makes Pascal VOC primarily an interchange and inspection format rather than a training format, and its role in production pipelines is largely limited to annotation tool export, QA review, and conversion to training-ready formats.

YOLO TXT: Structure, Normalized Coordinates, and the Ultralytics Ecosystem

The YOLO annotation format was introduced with the Darknet implementation of the original YOLO model and has been carried forward through every subsequent YOLO iteration. Ultralytics, the organization behind YOLOv5, YOLOv8, YOLO11, YOLO12, and YOLO26, uses a consistent variant of the Darknet format across all of its models. Because YOLO models dominate production real-time object detection in 2026, the YOLO TXT format has become the practical standard for any pipeline where inference speed is a primary requirement.

File Structure

YOLO creates one TXT annotation file per image. The filename matches the image filename with a .txt extension. Each line in the file represents one annotated object and contains the class index followed by four floating-point coordinates. A companion YAML file defines the dataset structure, pointing to the directories for training images, validation images, and test images, and listing the class names in order so that class indices in the TXT files map to human-readable labels.

Coordinate System: Normalized Center XYWH

YOLO bounding box coordinates are normalized to the range [0, 1] relative to the image dimensions. The x_center and y_center values locate the center of the bounding box as fractions of the image width and height respectively. The width and height values are also expressed as fractions of the image width and height. This normalized representation means YOLO annotation files are valid regardless of whether images are resized, as long as the aspect ratio is preserved. Converting to absolute pixel coordinates requires multiplying the normalized values by the image dimensions.This is the most significant structural difference between YOLO and the other two formats. Pascal VOC uses absolute XYXY pixel coordinates. COCO uses absolute XYWH pixel coordinates. YOLO uses normalized center XYWH. A conversion error between any of these systems produces bounding boxes at incorrect positions, which trains the model on mislocated labels.

Class ID Convention and the COCO-to-YOLO Conversion Pitfall

YOLO class indices are always zero-indexed: the first class in the YAML configuration file is class 0, the second is class 1, and so on. COCO category IDs are not required to start at zero and in the standard COCO dataset begin at 1. When converting COCO annotations to YOLO format, the category_id values must be remapped to zero-indexed class indices. Failing to apply this remapping produces a class ID offset that shifts every predicted class by one position.As Ultralytics' official COCO-to-YOLO conversion documentation states: if negative class IDs appear after conversion, the COCO JSON likely uses category_id starting from 0, and 1 must be added to all category_id values before running the converter. Always verify the class mapping after conversion before beginning any training run.

Segmentation and Keypoint Extensions

YOLO TXT format has been extended to support instance segmentation and keypoint annotation in addition to bounding box detection. For segmentation, each line in the TXT file contains the class index followed by normalized polygon vertex coordinates: class_index x1 y1 x2 y2 and so on. For keypoints, the format adds keypoint coordinates and visibility flags after the standard bounding box fields.

YOLO11 and YOLO26 support all three annotation types using the same file format with different content structures per task type. This means a team that annotates with YOLO TXT format can train detection, segmentation, and pose estimation models from the same annotation pipeline without switching formats.

COCO vs Pascal VOC vs YOLO: Side-by-Side Comparison

The table below covers the key structural attributes of each format to support a direct comparison.

How to Choose the Right Annotation Export Format

The format decision follows directly from the training framework and model architecture the dataset is intended for. Applying three questions in sequence produces the correct format for almost every production use case.

Question 1: Which Model Architecture Will Train on This Dataset?

If the answer is any Ultralytics YOLO model from YOLOv5 through YOLO26, YOLO TXT is the required format. These models consume YOLO TXT natively and require a YAML configuration file that maps class indices to class names. COCO JSON can be converted to YOLO TXT using Ultralytics' built-in conversion tools, but the conversion must be verified for class ID alignment before training.If the answer is Detectron2, MMDetection, Mask R-CNN, or any research framework built around the COCO evaluation protocol, COCO JSON is the appropriate format. These frameworks expect annotations in COCO structure and use the COCO evaluation API to compute mAP, which requires COCO-formatted ground truth.If the dataset will be used with multiple frameworks or the target framework has not been finalized, COCO JSON is the safer default. It is convertible to YOLO TXT and Pascal VOC XML with established tooling, and it stores more annotation metadata than either alternative.

Question 2: Does the Dataset Include Segmentation or Keypoints?

If the annotations include instance segmentation masks or keypoints in addition to bounding boxes, Pascal VOC XML should not be the export format. Pascal VOC has limited support for keypoint annotations and is not the format expected by any major segmentation model architecture. COCO JSON or YOLO TXT (for Ultralytics segmentation models) are the appropriate choices.

Question 3: Will Annotation Files Be Reviewed Manually?

Pascal VOC XML's primary advantage is human readability. An annotator or QA reviewer who needs to inspect an annotation file and verify that labels are correct will find Pascal VOC XML significantly more readable than a COCO JSON file containing thousands of annotation objects or a YOLO TXT file of raw floating-point numbers. For annotation QA workflows where human inspection of individual files is part of the process, Pascal VOC XML export alongside the primary training format is a reasonable approach.

Converting Between Formats

Converting between these three formats is straightforward with standard tooling. Roboflow's format converter handles conversion between COCO, Pascal VOC, and YOLO formats and accounts for the coordinate system transformations automatically. Ultralytics provides a convert_coco() function in the ultralytics Python package for COCO-to-YOLO conversion. CVAT exports to all three formats from a single annotated dataset.

The conversion step that most commonly produces errors is COCO to YOLO class ID remapping. Always verify that class indices in the converted YOLO TXT files correspond correctly to the class order in the YAML configuration file before beginning training. A quick spot-check of several label files against the expected class list takes minutes and prevents the class offset problem from propagating into a full training run.

How Scematics Handles Annotation Export Across All Three Formats

Scematics exports to COCO JSON, YOLO (Darknet and Ultralytics variants), Pascal VOC, CreateML JSON, and Mask PNG from a single annotated dataset. Export format can be changed without re-annotating, and the platform handles coordinate system transformation automatically on export.

Annotate Once, Export to Any Format

For teams whose pipeline requirements evolve across a project (for example, prototyping with Detectron2 and moving to YOLO26 for production inference), annotating once and exporting to the required format on demand eliminates the rework that format lock-in creates. For more on annotation workflow and quality control before export, see the image annotation guide. For guidance on choosing an annotation platform that supports your target export format, see the best annotation tools comparison.