Based on the official Gravatar llms.txt documentation (API v3.0.0, updated April 2025), a comprehensive feature gap analysis was conducted for Cravatar. In 2024, Gravatar underwent a major overhaul—evolving from a pure avatar service into an “identity platform.”
A key sentence in the Gravatar documentation reads: “Don’t use MD5!” — they have explicitly deprecated MD5 in their documentation. Our migration direction toward SHA256 is therefore fully correct.
I. Avatar Image API (Core Capabilities)
Cravatar is largely aligned here; the SHA256 migration has just been completed (#1796).
Feature
Gravatar
Cravatar
Status
SHA256 hash
Completed
MD5 hash (backward compatibility)
Completed
s= size (1–2048)
—
r= rating (g/pg/r/x)
—
d=404
—
d=mp (mystery person)
—
d=identicon
—
d=monsterid
—
d=wavatar
—
d=retro
—
d=robohash
To be confirmed
Possibly missing
d=blank
To be confirmed
Possibly missing
d={url} custom default image
—
f=y force default image
To be confirmed
Possibly missing
.jpg/.png format suffixes
—
Short-term action: Confirm and implement support for robohash, blank, and f=y.
II. REST API v3 (Largest Gap)
The core change in Gravatar v3 is the introduction of a full user profile API.
Profile Endpoints
Endpoint
Gravatar v3
Cravatar
GET /v3/profiles/{hash} — User profile
GET /v3/profiles/{hash}/inferred-interests — AI-inferred interests
(experimental)
GET /v3/qr-code/{hash} — QR code
Bearer Token authentication
OpenAPI specification
Profile Data Model
Gravatar v3’s Profile includes the following fields—none of which Cravatar currently supports:
display_name / first_name / last_name — Display name
pronouns / pronunciation — Pronouns and pronunciation guidance
location / timezone / languages — Geographic and language information
Complete Avatar API support — Add d=robohash, d=blank, and f=y; requires only minor changes to avatar.php.
QR Code API — Standalone functionality, independent of the Profile system, with strong user visibility.
.json Profile format — Widely relied upon by third-party tools.
Mid-term (Requires architectural expansion)
REST API v3 Profile endpoints — Core differentiator; requires database schema extension and new API layer.
Hovercards — High user visibility, but depends on Profile data.
Bearer Token authentication — Prerequisite for Profile API.
Long-term (Strategic)
SDKs (Android/iOS) — Require Profile API to be in place first.
Quick Editor — Requires OAuth infrastructure.
AI-inferred interests — Experimental; can be deferred pending further evaluation.
Verified Accounts — Requires integration with OAuth flows of multiple platforms.
V. Strategic Considerations
Gravatar v3’s direction is unequivocal: evolving from an “avatar service” into a decentralized identity platform. If Cravatar remains solely an avatar proxy, it risks long-term marginalization.
However, Cravatar holds distinct advantages:
Network accessibility in China (Gravatar is unstable domestically)
QQ Mail avatar matching (not supported by Gravatar)
Localized operational capability
Recommended differentiation strategy:
Maintain 100% compatibility with Gravatar’s avatar API—including all v3 parameters.
Implement Profile API features selectively, prioritizing those most valuable to the WordPress ecosystem.
Format Suffixes: No suffix → returns WebP / .jpg → returns JPEG / .png → returns PNG
Edge Cases: Empty hash / Short hash / s=0 / s=9999 — none cause crashes; all return the default image
Conclusion: The Cravatar avatar image API is now 100% compatible with Gravatar, with no missing features. Remaining differences lie solely in REST API v3 (Profile, QR Code, SDK).
The wpavatar component appears on the cravatar.com homepage; CSS class names are correct
SHA256 hash usage
Avatar URLs are dynamically loaded; static HTML cannot verify hash length
Note: The WPAvatar backend settings page requires a cravatar.com administrator account, which is unavailable on Elementary OS. Please have an authorized colleague complete this verification or provide a test account.
III. Performance Benchmark
Scenario
Avg. Response Time (10 runs)
Result
Cached MD5 avatar
201 ms
Cached SHA256 avatar
206 ms
Uncached random hash (Gravatar fallback)
729 ms
d=identicon generation
787 ms
d=robohash generation
804 ms
Cache hits ~200 ms — excellent performance
Uncached/generation requests ~730–800 ms — primarily due to Gravatar fallback latency
No significant performance difference between MD5 and SHA256 (201 vs. 206 ms)
IV. Summary
API Testing: All Passed — Hash types, default images, sizing, rating, forced defaults, format suffixes, and multi-node support all function correctly.
Robust Boundary Handling — Invalid sizes fall back to minimum size; oversized values are capped at 2048; invalid hashes return default avatars.
Performance Meets Requirements — Cache hits average ~200 ms; SHA256 migration introduces no performance degradation.
Pending Items — Verification of WPAvatar 1.9.5 backend settings (requires admin access); confirmation of SHA256 hash usage on frontend (requires dynamic browser inspection).
To be confirmed
