Avatars in WordPress: Where They Come From and What They Leak

Core WordPress has no avatar storage. It has an integration with Gravatar, an external service, and everything else is a plugin filling that gap. Understanding which of those you are running changes both your privacy position and the number of third-party requests on every page with comments.

How the default actually works

When WordPress renders an avatar, it takes the person's email address, normalises it, hashes it, and builds a URL pointing at the Gravatar service with that hash in the path. The service returns either that person's uploaded picture or a generated fallback.

Nothing is stored locally. The image is fetched by the visitor's browser, not by your server, every time the page is displayed.

The controls in core live under Settings → Discussion:

• Show Avatars. The master switch for the whole mechanism.
• Maximum rating. A content rating filter applied to fetched images.
• Default avatar. What appears when someone has no Gravatar account — a generic silhouette, a blank space, or one of several generated patterns derived from the same hash.

Themes call this through get_avatar(), and the output can be intercepted with the get_avatar filter, which is exactly how every local-avatar plugin works.

The privacy implication most people miss

Here is the part that rarely makes it into avatar tutorials.

A page showing thirty comments makes thirty requests from your visitor's browser to a third-party server. Each request carries the hash of a commenter's email address, plus the visitor's IP address, user agent and — depending on referrer policy — the URL of the page they are reading.

Two consequences follow.

A hash is not anonymisation. It is a one-way function, but email addresses are low-entropy and heavily reused. Anyone holding a list of addresses can hash the list and match. The practical effect is that the identity of your commenters is legible to a party that is not you.

Your visitors are disclosed to a third party. Not your commenters — your readers. Their browsers contact an external service on every page load, without being asked.

If you operate under GDPR or a similar regime, that combination is a processing question your privacy policy has to answer honestly, and arguably a consent question. Sites that already run a consent mechanism should decide whether avatar loading belongs behind it, because the request happens whether or not the visitor accepted anything.

The three realistic configurations

Gravatar as shipped is fine for a personal blog with light comment volume where you have said so in your privacy policy.

Off entirely is a legitimate design choice, not a compromise. Many well-designed comment sections use initials or a coloured shape drawn in CSS instead. If the theme leaves a hole where the image was, a small custom CSS rule closes it.

Local avatars — the plugin category rather than any particular product — store an uploaded image in the media library and swap it in through the same filter core uses. What to look for when choosing one: whether it falls back to Gravatar when no local image exists (many do, which quietly reinstates the problem you were solving), whether it generates properly sized files rather than scaling one large image in the browser, and whether uploaded avatars go through your normal image optimisation pipeline.

A fourth option exists for larger sites: proxy and cache avatars on your own domain. It keeps visitor IP addresses private and removes the third-party connection, at the cost of running a cache you have to maintain.

Author avatars versus commenter avatars

These are the same mechanism but different risk. Author avatars belong to a handful of accounts you control, and giving those people a proper local image is straightforward — it is also the case where a good picture materially improves the page.

Commenter avatars are the volume problem, and the ones carrying other people's data. It is entirely reasonable to run local avatars for authors and no avatars at all in the comment list. If comments are more trouble than they are worth to you, disabling them removes the question completely.

Make the call, then write it down

Open Settings → Discussion and look at what your site is doing right now. If avatars are on, either accept the third-party request and disclose it plainly in your privacy policy, or switch to local images and gain a little speed as a side effect.

What you should not do is leave it at the default because it was the default, then answer a data question badly a year later.