Pose Estimation Models Compared: MediaPipe, MoveNet, YOLO and More

New to the concept itself? Start with what pose estimation is; this page is about choosing among the actual models. For the whole job in order, from the concept to a shipped rep counter and form cue, follow the camera-coaching reading path.

The models you actually choose among#

Keypoint counts below are stable facts you can rely on. Everything about speed is described as positioning, not a number — fps and accuracy vary wildly by device, resolution, and delegate, so any benchmark must be verified on your own target hardware (as of 2026, verify).

• MediaPipe / BlazePose (Google). Predicts 33 landmarks (a superset of the 17 COCO keypoints, adding face, hand, and foot points). It is designed for on-device, real-time use and outputs both 2D image-coordinate landmarks and 3D world landmarks in meters, plus per-landmark visibility. It is single-person focused: the model card says it tracks one person, and while the Tasks API has a num_poses setting, it defaults to 1 and the card does not evaluate more. License: Apache-2.0 for the framework and, per Google's model card, the models.
• MoveNet — Lightning vs Thunder (TensorFlow / Google). Detects 17 keypoints. Shipped in two variants: Lightning is tuned for latency-critical/speed use, Thunder for higher accuracy. Single-person oriented; commonly used for browser/web and lightweight mobile. License: Apache-2.0.
• YOLO-pose / Ultralytics (YOLO26-pose). Ultralytics' pose docs now present YOLO26 as the current generation. The default models predict the 17 COCO keypoints, and the COCO-Pose dataset config stores each one as (x, y, visible). It is multi-person capable, detecting people and their keypoints in one pass. Five sizes (n/s/m/l/x) trade speed for accuracy. License: AGPL-3.0 (strong copyleft) with a paid Enterprise License to bypass it — see the licensing note below.
• PoseNet (legacy, TensorFlow.js). 17 keypoints per pose, and it can detect multiple poses. Its standalone posenet package is deprecated in favor of the pose-detection package, which serves MoveNet, BlazePose and PoseNet itself. Prefer MoveNet or BlazePose for new projects. License: Apache-2.0.
• OpenPose (CMU, research). A real-time multi-person system built on Part Affinity Fields. Its output document names the BODY_25, COCO_18, MPI_15 and BODY_25B body models, with output diagrams for BODY_25 and the 18-point COCO set. Heavy and GPU-oriented, strong for research and multi-person, less suited to lightweight on-device. License: academic or non-profit noncommercial research only from CMU — commercial use needs a separate license.

Each model has its own page with the detail this overview leaves out: MediaPipe Pose Landmarker models, MoveNet models, ML Kit pose detection, Ultralytics YOLO pose models, RTMPose models and OpenPose models. Every keypoint index, scheme by scheme, is in the pose keypoint maps.

Comparison table#

Positioning, not fabricated benchmarks. Confirm licenses and any speed claim before you ship.

The licensing trap (read before you commit)#

Two of these models carry license terms that can block a commercial product, and they are easy to miss because the code is free to download:

• Ultralytics YOLO is AGPL-3.0. AGPL is a strong reciprocal (copyleft) license: if you distribute or even offer a network service built on AGPL code, its terms can require you to release your own source under the same license. Ultralytics sells a paid Enterprise License specifically to lift that obligation. Treat "which license" as a real legal decision, not a footnote — verify the current terms and talk to counsel before building a closed-source product on it.
• OpenPose is noncommercial research only. CMU's license grants academic or non-profit noncommercial research use, and its README points anyone interested in a commercial license to a separate licensing page. Do not ship it in a paid or commercial app without clearing licensing first. OpenPose alternatives compares the options and their licences.

The Apache-2.0 options (MediaPipe/BlazePose, MoveNet, PoseNet) are the most permissive here. One gap to close: the MoveNet SinglePose model card states Apache 2.0, but the text of the MultiPose card carries no licence line of its own, so confirm its terms before you ship it. For what each license file and model card actually says, model by model, see pose estimation model licenses.

How to decide — by use case#

There is no single winner; the right model follows your scene and constraints:

• Single user, on-device, needs joint angles (and optionally 3D): MediaPipe/BlazePose. The 33 landmarks and monocular 3D world landmarks make it the default for a private, phone-based rep-counting or form-feedback app.
• Single user, pure speed, browser or lightweight mobile, 2D only: MoveNet — Lightning when responsiveness beats precision, Thunder when you can afford more compute for a cleaner pose. If it comes down to these two, MediaPipe vs MoveNet compared side by side decides it by what you compute from the keypoints.
• Multiple people at once (group class, gym floor, sports scene): YOLO-pose (mind AGPL-3.0) or OpenPose (mind the non-commercial license). Multi-person also needs a separate cross-frame tracking layer to keep identities stable. For one user against a group, MediaPipe vs YOLO pose sets the two side by side.
• New build: avoid PoseNet — it is legacy; pick MoveNet or BlazePose instead.

If you would rather not choose and maintain a model at all, a managed motion SDK bundles pose plus rep/form logic — see AI workout tracking APIs for the buy option.

MediaPipe vs MoveNet, head to head#

Most single-user fitness builds come down to these two Google models, and the choice settles on what you will compute from the keypoints, not on a benchmark screenshot. MediaPipe Pose gives you geometry, 33 landmarks plus world landmarks in meters with the origin between the hips, which is what joint angles that must survive viewpoint changes need; MoveNet gives you speed and simplicity, the 17 COCO keypoints in 2D, with Lightning for the lowest latency and MultiPose when more than one person is in frame. Outputs, variants, the published speed figures and licences are set side by side in the full MediaPipe vs MoveNet comparison.

The honest limits#

• A normal RGB phone camera is enough. No depth sensor or LiDAR is required for 2D or monocular 3D pose.
• Monocular 3D depth is estimated, not measured. BlazePose world landmarks are hip-relative and inferred from a single camera; depth is unreliable for occluded or extremity joints and degrades on out-of-plane movement. It is not sensor-grade — treat the depth axis as lower-confidence than x/y, smooth it, and validate. More reliable 3D needs multi-camera rigs or depth sensors.
• Benchmarks are condition-dependent. Leaderboard fps and accuracy assume specific hardware, lighting, and framing. Do not present a lab number as your app's real-world result; test on your own cameras, lighting, distances, and exercises.
• Form feedback is a coaching aid, not medical or physical-therapy advice. Monocular angle error, occlusion, and depth ambiguity mean it can be wrong; it cannot judge pain or injury. Recommend a professional for anything injury-related.
• Streaming raw video to a server is privacy-sensitive. Keeping inference on-device (video never leaves the phone) is the strongest privacy posture.

Before you ship#

Pick by use case, then verify: confirm the current license (especially OpenPose non-commercial and YOLO AGPL-3.0), re-check any fps/accuracy claim on your own target hardware, and validate monocular 3D on real users rather than trusting a lab figure. When you are ready to wire it into a camera feed, see the camera pose tracking guide for implementation.