How Gravatar exposes WordPress user emails

How Gravatar exposes WordPress user emails requires one important clarification before anything else:

Modern WordPress does not normally send a user’s email address to Gravatar in plain text simply because an avatar is displayed.

Instead, WordPress derives a deterministic identifier from the email address and places that identifier in the Gravatar avatar URL.

In current WordPress versions, the simplified process is:

user@example.com
↓
trim whitespace
↓
convert to lowercase
↓
SHA-256
↓
Gravatar identifier
↓
https://secure.gravatar.com/avatar/HASH

That is better described as:

email-derived identifier exposure

rather than:

plain-text email transmission.

But that distinction does not make the privacy question disappear.

The identifier is deterministic: the same normalized email address produces the same hash. Gravatar uses that value as the primary identifier for avatars and profiles, and when a visitor’s browser loads the avatar, it also creates a network request to external infrastructure.

The real privacy discussion therefore has several layers:

• the email-derived hash appearing in avatar URLs;
• the possibility of testing known or predictable email addresses against that hash;
• linkability of the same Gravatar identity across different sites;
• the browser contacting Gravatar whenever an externally hosted avatar is rendered;
• the visitor’s own network information being visible to the external service.

This guide explains exactly how WordPress builds Gravatar URLs, why hashing is not the same as encryption, what changed when WordPress moved from MD5 to SHA-256, how email guessing differs from cryptographic hash reversal, how guest comments are affected and how local avatars can remove the external request entirely.

What is Gravatar?

Gravatar is an avatar service that associates profile images and profile information with email-derived identifiers.

The basic idea is simple.

A user registers an email address with Gravatar and associates an avatar with it.

Another application can then derive the corresponding identifier and request the image.

This lets one avatar follow a user between websites

Conceptually:

Email address
↓
Gravatar identifier
↓
avatar service
↓
same profile image
across supported websites

WordPress has long integrated with Gravatar

Functions such as:

get_avatar()

can retrieve an avatar for:

• a WordPress user;
• an email address;
• a comment;
• a post author;
• an existing Gravatar identifier.

The official WordPress get_avatar() documentation describes the function as returning the avatar <img> element for those identities.

get_avatar() does not normally download the image into WordPress

Instead, WordPress generates HTML containing an external URL.

Conceptually:

WordPress generates:

<img
    src="https://secure.gravatar.com/avatar/HASH"
>

Then the browser loads the avatar

The actual network path becomes:

visitor
↓
example.com
↓
HTML contains Gravatar URL
↓
visitor browser
↓
secure.gravatar.com
↓
avatar image

This distinction matters

The WordPress server can generate the URL, but the visitor’s browser is typically the system making the final image request.

How WordPress creates the Gravatar identifier

Current WordPress Core handles Gravatar identity generation inside:

get_avatar_data()

The official WordPress get_avatar_data() documentation shows that Core obtains the user’s or commenter’s email address and normalizes it before hashing.

The normalization process

Conceptually:

$email = strtolower(
    trim( $email )
);

Then WordPress calculates

hash(
    'sha256',
    $email
);

This produces a SHA-256 identifier

For example:

user@example.com
↓
SHA-256
↓
a long hexadecimal string

WordPress then builds the Gravatar URL

Current Core uses:

https://secure.gravatar.com/avatar/HASH

plus optional parameters for things such as:

• avatar size;
• default avatar;
• rating;
• forced default behavior.

WordPress changed from MD5 to SHA-256

This is important because many tutorials still describe the old behavior.

The WordPress Core documentation records that:

WordPress 6.8
→ Gravatar URLs changed
  to SHA-256 hashing

Before that, MD5 was traditionally used

This means an article saying:

WordPress always exposes
an MD5 hash of the email

is outdated for current WordPress.

Gravatar itself now documents SHA-256 as the standard identifier

The current Gravatar developer documentation instructs applications to:

trim the email
↓
lowercase it
↓
SHA-256 hash it

Why does normalization matter?

Consider:

User@Example.com

and:

 user@example.com 

Without normalization

those strings produce different hashes.

With normalization

trim
+
lowercase

both become:

user@example.com

This makes the Gravatar identity deterministic

The same normalized email consistently produces the same identifier.

That consistency is the whole point of Gravatar

But it is also central to the privacy discussion.

Does WordPress send the email address itself to Gravatar?

Normally, not in the avatar URL.

The URL contains the derived identifier

For current WordPress:

SHA-256(
    strtolower(
        trim( email )
    )
)

So this:

john@example.com

does not normally become:

https://secure.gravatar.com/avatar/
john@example.com

It becomes

https://secure.gravatar.com/avatar/
SHA256_IDENTIFIER

This distinction needs to be stated accurately

Calling that plain-text email transmission would be technically incorrect.

But is a hash anonymous?

Not automatically.

A cryptographic hash transforms input into a fixed-length output.

For example

email
↓
hash function
↓
identifier

A hash is not encryption

Encryption is intended to be reversible using a key.

plaintext
↓
encryption + key
↓
ciphertext
↓
decryption + key
↓
plaintext

A cryptographic hash is designed as a one-way operation

input
↓
hash
↓
output

There is no normal:

decrypt SHA-256

operation.

So can someone recover the email from the hash?

Not by mathematically reversing SHA-256 in the way one decrypts ciphertext.

But there is another approach

If somebody can guess candidate email addresses, they can calculate their hashes and compare the results.

This is a dictionary-style test

Suppose a public Gravatar URL contains:

HASH_X

An observer suspects the email might be

john@example.com

They calculate:

SHA256(
    "john@example.com"
)

If the result equals HASH_X

they have confirmed the candidate.

This is not hash reversal

It is:

guess
↓
hash guess
↓
compare

The distinction matters

SHA-256 remains cryptographically strong.

The privacy limitation comes from the predictability of the input domain.

Email addresses are not random 256-bit secrets

Real email addresses often follow patterns such as:

firstname.lastname@company.com

firstname@company.com

info@company.com

admin@company.com

support@company.com

If the possible address is already suspected

confirming it requires hashing only that candidate.

Consider a company directory

Suppose the public website identifies the author as:

Jane Smith
Example Corporation

Likely address candidates may include

jane.smith@example.com
jsmith@example.com
jane@example.com

An observer can calculate each identifier

candidate 1
↓
SHA-256
↓
compare

candidate 2
↓
SHA-256
↓
compare

candidate 3
↓
SHA-256
↓
compare

This is why hashing alone should not be equated with anonymity

The identifier may still be linkable to an email where the candidate space is manageable.

SHA-256 is still better than MD5 cryptographically

The move from MD5 to SHA-256 modernizes the identifier scheme.

But stronger hashing does not solve every privacy property

The same structural property remains:

same normalized email
↓
same deterministic identifier

If somebody already knows a candidate email

they can calculate the SHA-256 value just as WordPress does.

The question is therefore not:

Can someone crack SHA-256?

It is often:

Can someone test likely
email addresses against
a public identifier?

Those are very different threat models.

What exactly becomes public?

If a page includes a Gravatar image URL in its HTML, the email-derived identifier may become visible in:

• page source;
• browser Developer Tools;
• network logs;
• cached HTML;
• crawler data;
• screenshots of network tools;
• third-party archives or datasets that capture HTML.

For example

<img
    src="https://secure.gravatar.com/avatar/
    84059b07..."
>

The email is not printed

But its deterministic identifier is exposed as part of the resource URL.

Public avatar URLs can create cross-site linkability

This is another important issue.

Suppose the same user participates on:

site-a.example

site-b.example

site-c.example

If every site generates the same Gravatar identifier

an observer may be able to recognize that:

HASH_X on site A
=
HASH_X on site B
=
HASH_X on site C

Even before recovering the underlying email

the identifier can potentially act as a stable cross-site pseudonymous marker.

This is what linkability means

Separate appearances can be associated with the same underlying identity.

The benefit and the privacy tradeoff are two sides of the same design

Gravatar works because:

same email
=
same identifier
=
same avatar everywhere

But that also means

same identifier
=
appearances can potentially
be correlated across sites

The feature requires persistence

The privacy tradeoff comes partly from that persistence.

Guest commenters are affected too

This is not limited to registered WordPress users.

WordPress’s current avatar-resolution logic can obtain an email address from:

WP_Comment

data when the commenter is not associated with a registered user.

For a guest comment

WordPress may have:

comment_author
comment_author_email

The email can then be used to derive the avatar identifier

Conceptually:

guest enters email
↓
WordPress stores comment email
↓
get_avatar( comment )
↓
email extracted
↓
SHA-256 identifier
↓
Gravatar URL

The commenter may never have created a Gravatar account

The external request can still occur because WordPress can request a Gravatar URL and use a configured default image when no matching profile exists.

That distinction is important

No Gravatar account
≠
no Gravatar request

Default avatars can still involve Gravatar infrastructure

WordPress supports defaults such as:

• Mystery Person;
• Blank;
• Gravatar Logo;
• Identicon;
• Wavatar;
• MonsterID;
• Retro;
• Robohash;
• Initials;
• generated color options in current Core.

The important distinction is how the final avatar is delivered

If WordPress still generates:

https://secure.gravatar.com/avatar/HASH?d=...

then an external Gravatar request still exists even if the returned result is a default avatar.

Showing a generic avatar does not necessarily mean the request stayed local

Always inspect the final URL.

The second privacy layer: the visitor contacts Gravatar

The email-derived identifier is only one part of the architecture.

The avatar itself is externally hosted

The visitor’s browser requests:

secure.gravatar.com

That request necessarily exposes network information

Like other web services, remote infrastructure receives information required to establish and process the connection.

This can include

• IP address;
• browser information;
• request time;
• requested avatar URL;
• referrer information where browser policy permits it;
• other standard HTTP/network metadata.

The current Automattic privacy documentation describes automatic collection of technical data

It includes information typically made available by browsers and servers, such as:

• IP address;
• browser type;
• language preference;
• referring site;
• date and time of access;
• operating system.

This means the privacy model is broader than email hashing

The path is:

WordPress user email
↓
deterministic identifier
↓
public Gravatar URL

AND

visitor browser
↓
Gravatar request
↓
network metadata

For the wider architectural discussion, see WordPress privacy and third-party requests.

Does Gravatar receive every visitor’s email?

No.

Do not confuse the identity represented by the avatar with the person viewing it.

Suppose Alice authored the comment

WordPress derives:

Alice's email
↓
Alice's Gravatar identifier

Bob visits the page

Bob’s browser then requests:

Alice's Gravatar avatar URL

The Gravatar request can therefore expose

Alice-derived identifier
+
Bob's network request metadata

Those are two different identities

This distinction is useful when reasoning about privacy.

Does HTTPS solve the privacy issue?

HTTPS is important.

Current WordPress Core always constructs Gravatar URLs over:

https://

The Core changelog records this behavior from WordPress 6.7 onward.

HTTPS protects the request in transit

It prevents ordinary network observers between the browser and Gravatar from reading the request contents directly.

But HTTPS does not hide the request from the destination server

The Gravatar service still needs to know:

which avatar URL
was requested

in order to return the image.

HTTPS provides transport confidentiality

It does not mean:

no third party receives data.

Is the hash personal data?

That is ultimately a legal question and depends on context and jurisdiction.

Technically, however, the identifier is linked to a normalized email address

It is intentionally generated from that address and is stable for that input.

It can therefore be useful to treat it as a pseudonymous identifier during privacy analysis

rather than casually assuming:

hashed
=
anonymous
=
irrelevant.

Hashing and anonymization are not synonyms

True anonymization requires considering whether a person can reasonably be reidentified or linked using available information.

A deterministic unsalted email hash has different properties from a random identifier

Compare:

random UUID generated by site
↓
no mathematical relationship
to email

with:

SHA256(
    normalized email
)
↓
deterministic relationship
to email

Anyone can reproduce the second identifier

if they know or can guess the email address.

Why isn’t the hash salted?

Because Gravatar needs independent websites to generate the same identifier.

If every site used its own secret salt

site A:
hash( secretA + email )

site B:
hash( secretB + email )

the identifiers would differ.

Gravatar would no longer have a universal lookup key

The service depends on deterministic cross-site derivation.

This is a design tradeoff

Universal avatar lookup
requires reproducible identity

Reproducible identity
creates linkability

This does not mean Gravatar is malicious

It means the architecture has privacy properties that administrators should understand.

Gravatar’s own documentation calls the email hash its primary identifier

The current Gravatar developer documentation states that avatar images and profiles are accessed using the hash derived from an email address.

This is not an accidental implementation detail

It is the identity model of the service.

Can a search engine see Gravatar hashes?

If the hash appears in public HTML, a crawler capable of processing that HTML can potentially encounter it.

For example

public author page
↓
HTML
↓
Gravatar img URL
↓
email-derived identifier

Whether a particular search engine indexes or uses it is a separate question

But technically the value is public when embedded into a public page.

Do not place sensitive information in a public identifier simply because it is hashed

This is a broader engineering lesson.

How can you see whether your WordPress site uses Gravatar?

The fastest test is the browser Network panel.

Step 1: open a page with avatars

Examples include:

• comments;
• author boxes;
• member directories;
• community pages;
• admin Users screens;
• custom dashboards.

Step 2: open Developer Tools

Select:

Network

Step 3: reload the page

Search requests for:

gravatar

You may see

secure.gravatar.com/avatar/...

Step 4: inspect the request URL

The long hexadecimal path is the Gravatar identifier.

Step 5: inspect page source too

Search for:

secure.gravatar.com

The request may already be present in the HTML

before any JavaScript executes.

Step 6: test multiple areas

A site may remove Gravatar from the frontend while leaving it active in:

• wp-admin;
• custom user interfaces;
• comments;
• plugins using get_avatar().

Audit site-wide behavior

How WordPress plugins retrieve avatars

A plugin should normally use WordPress APIs such as:

get_avatar()

or:

get_avatar_url()

rather than building Gravatar URLs manually

This gives WordPress and other plugins the opportunity to filter avatar behavior.

WordPress provides avatar filters

These include:

pre_get_avatar_data
get_avatar_data
get_avatar_url
get_avatar

That means Gravatar can be replaced centrally

A local-avatar system can intercept WordPress’s normal avatar lookup and return a local image instead.

This is much better than editing every template individually

Bad architecture:

comments.php
→ custom avatar

author.php
→ custom avatar

users.php
→ custom avatar

plugin A
→ still Gravatar

plugin B
→ still Gravatar

Better architecture

WordPress avatar API
↓
central avatar filter
↓
local avatar URL

Anything using the standard API benefits automatically

TheOneWP Local Avatar uses this model

TheOneWP Local Avatar replaces the normal avatar result through the WordPress avatar system rather than requiring individual integrations everywhere an avatar is displayed.

The module stores profile pictures locally

The verified implementation allows logged-in users to upload profile images that are stored on the WordPress installation. theonewp.WordPress.2026-08-18 (1).xml

That changes the network path

With Gravatar:

visitor
↓
WordPress page
↓
secure.gravatar.com
↓
avatar

With a local avatar

visitor
↓
WordPress site
↓
local uploads
↓
avatar

The external image request disappears for users with local avatars

But there is one additional decision.

What happens when the user has no local avatar?

TheOneWP Local Avatar supports two possible behaviors.

Default behavior

No local avatar
↓
Gravatar fallback

Privacy-oriented behavior

No local avatar
↓
locally generated initials
↓
no Gravatar request

The Gravatar fallback setting is therefore important

If the goal is:

zero Gravatar requests

it is not enough to give only some users local avatars.

The fallback must also remain local

The verified Local Avatar implementation can generate an initials placeholder as an inline SVG data URI when Gravatar fallback is disabled, meaning no external avatar request is required for users without an uploaded picture. theonewp.WordPress.2026-08-18 (1).xml

This also applies to guest commenters

The module’s verified behavior accounts for:

WP_Comment

avatar resolution as well as registered WordPress users. theonewp.WordPress.2026-08-18 (1).xml

Why use an initials placeholder?

It provides a stable visual identity without needing:

• a third-party profile service;
• a remote image;
• a remote hash lookup;
• a manually uploaded file.

For example

Jane Smith
↓
JS

John
↓
JO

The visual result can be generated locally

No avatar lookup needs to leave the website.

What if you still want Gravatar?

That is a valid design choice.

Gravatar provides real benefits

• users do not need to upload the same avatar repeatedly;
• profile images remain synchronized across participating sites;
• WordPress integration is mature;
• implementation is simple.

Privacy engineering does not require declaring every external service forbidden

The important thing is understanding the tradeoff.

The decision can be framed as

Convenience:
global avatar identity

versus

Privacy/control:
local avatar infrastructure

Some sites may reasonably keep Gravatar

Examples might include:

• public developer communities where Gravatar is expected;
• blogs where authors deliberately use public Gravatar identities;
• sites whose privacy architecture explicitly includes the service.

Other sites may prefer local avatars

Examples include:

• employee portals;
• private communities;
• membership platforms;
• client portals;
• privacy-sensitive sites;
• sites designed to minimize third-party requests.

Should you disable avatars entirely?

That is another option.

WordPress exposes avatar-display settings in:

Settings
↓
Discussion

If avatars provide no useful functionality

disabling them can be simpler than replacing their provider.

But test the site first

Themes and plugins may rely on avatars for:

• comments;
• author cards;
• member listings;
• activity feeds.

Removing avatars can create empty layouts

A privacy improvement should not become an accidental design regression.

Local avatars provide a middle ground

keep avatar UX
+
remove external avatar dependency

Does using a local avatar hide the user’s email?

It removes the email-derived Gravatar identifier from that local avatar URL when correctly implemented.

A local URL might look like

https://example.com/
wp-content/uploads/
avatars/user-123.webp

That URL should not be derived directly from the user’s email

Prefer:

• attachment IDs;
• user IDs where appropriate;
• randomized filenames;
• other non-email-derived identifiers.

Do not solve Gravatar privacy by naming files after the email

This:

john@example.com.jpg

would be a magnificent demonstration of technically removing the hash while making the original problem substantially more obvious.

Local storage still needs privacy design

A profile image may itself be personal data.

You still need to think about

• who can upload it;
• who can view it;
• where it is stored;
• how it is removed;
• backup retention;
• user deletion workflows.

Removing a third-party dependency does not eliminate all privacy obligations

It changes the data path and gives the site owner more direct control.

WordPress user emails are sensitive application data

WordPress stores registered user email addresses in its own user data.

Commenters can also provide email addresses

Depending on site configuration.

These addresses serve legitimate application purposes

Such as:

• account recovery;
• notifications;
• comment identity;
• administration.

The question is whether every use of that address is necessary

If an email is required for:

password reset

that does not automatically mean it also needs to become the basis of:

a public cross-site avatar identifier.

Purpose matters

Data minimization can include asking:

Why is this field being used
for this secondary feature?

Gravatar and public author profiles

Author pages deserve particular attention because they can expose multiple pieces of contextual information together.

For example

Author name:
Jane Smith

Company:
Example Inc.

Gravatar hash:
HASH_X

The contextual information can reduce the email-guessing search space

Possible candidates become easier to generate.

This is why threat models depend on context

A random hash alone reveals much less than:

hash
+
full name
+
company domain
+
username

Privacy risks combine

Individual pieces of information that appear harmless can become more identifying when correlated.

WordPress usernames and Gravatar

Do not assume hiding an email address from the page is the end of user-identity exposure.

WordPress can also expose:

• display names;
• author slugs;
• usernames in some configurations;
• biographical information;
• profile links.

Gravatar is one piece of the identity surface

For broader account architecture, see WordPress user meta, explained and WordPress user roles and capabilities, explained.

Does disabling Gravatar improve performance?

It can.

Each external avatar can require another resource request

A comment thread with:

20 different commenters

can create multiple avatar requests.

Browser caching may reduce repeated transfers

But the site still depends on:

• external DNS;
• external connection setup;
• external response time;
• external availability.

Locally hosted avatars can simplify the dependency graph

Especially when the site’s own CDN already serves uploaded media.

Privacy and performance often align here

Removing an unnecessary external request can mean:

less external data exposure
+
fewer origins
+
simpler waterfall
+
greater operational control

See CDN vs. self-hosted assets in WordPress for the broader asset-delivery tradeoff.

How to audit Gravatar across a WordPress site

1. Test the frontend while logged out

Look at:

• posts with comments;
• author archives;
• team pages;
• member directories.

2. Search the Network panel for gravatar

secure.gravatar.com

3. Inspect the rendered HTML

Search for:

gravatar.com/avatar

4. Test wp-admin

WordPress administration screens may show avatars in:

• admin bar;
• Users;
• comments;
• dashboard areas.

5. Test registered users without Gravatar accounts

A fallback request may still occur.

6. Test guest comments

Use an email address that is not associated with a registered account.

7. Enable local avatars

Repeat the Network test.

8. Test users without local uploads

If Gravatar remains enabled as fallback, requests may still appear.

9. Disable the Gravatar fallback

Then confirm:

no gravatar.com requests

on the relevant avatar surfaces.

10. Test plugin-generated avatars

If a plugin uses:

get_avatar()

a central replacement should normally affect it.

But a plugin may build Gravatar URLs manually

That would bypass standard WordPress avatar filters.

Search custom code when requests remain

Useful strings include:

gravatar.com
secure.gravatar.com
get_avatar(
get_avatar_url(

Do not assume one setting controls every custom implementation

How to replace Gravatar correctly

A robust replacement should work through WordPress’s avatar APIs.

Useful extension points include

pre_get_avatar_data

get_avatar_data

get_avatar_url

get_avatar

Prefer replacing the avatar data before HTML is built

Where appropriate, returning a local URL through the avatar-data layer can preserve the rest of WordPress’s normal:

• size handling;
• classes;
• loading attributes;
• alt text;
• HTML generation.

Replacing final HTML can work too

But then your code takes responsibility for recreating the entire avatar element correctly.

WordPress explicitly exposes pre_get_avatar_data for short-circuiting avatar retrieval

If a plugin supplies a URL there, Core can skip the normal Gravatar-generation path.

This is useful for local avatar systems

Conceptually:

get_avatar()
↓
pre_get_avatar_data
↓
local avatar exists?
│
├── yes
│   └── return local URL
│
└── no
    └── choose local fallback
        or continue to Gravatar

Do not make the local fallback secretly remote

For example:

No avatar
↓
local-avatar plugin
↓
falls back to Gravatar anyway

means the external privacy path still exists for anyone without an upload.

A true zero-request fallback must be local

Options include:

• initials;
• local default image;
• generated SVG;
• CSS-only placeholder.

TheOneWP Local Avatar uses an inline initials option

When its Gravatar fallback is disabled, users without an uploaded image receive a locally generated initials placeholder rather than another network lookup. theonewp.WordPress.2026-08-18 (1).xml

Local avatar security still matters

Allowing profile image uploads introduces file-handling responsibilities.

Check more than the filename extension

A file named:

avatar.jpg

is not necessarily a real JPEG image.

Uploads should be validated

Useful controls include:

• MIME allowlist;
• image-content validation;
• ownership checks;
• capability checks;
• safe WordPress upload APIs.

The verified TheOneWP implementation performs independent image validation

Its Local Avatar workflow checks accepted image types and verifies that uploaded content is a readable image before storing it. theonewp.WordPress.2026-08-18 (1).xml

Users should manage only their own avatars

A profile-image system must not accidentally let:

User A
↓
select/delete
User B's avatar

Ownership validation is therefore important

The verified Local Avatar implementation checks ownership before selection or deletion of stored profile pictures. theonewp.WordPress.2026-08-18 (1).xml

What should you put in a privacy policy?

The exact wording depends on your site’s legal context.

Technically, if Gravatar is used, relevant facts may include

• avatar images are obtained from an external service;
• an identifier derived from the user’s or commenter’s email may be used for the lookup;
• the visitor’s browser may connect directly to external avatar infrastructure;
• the external service may receive standard network information.

Do not copy generic privacy text without verifying the implementation

If your site uses only local avatars, a paragraph claiming every commenter is sent to Gravatar would be inaccurate.

Privacy documentation should match the current network behavior

For the broader auditing process, see WordPress privacy and third-party requests.

Does a consent banner solve Gravatar?

Not by itself.

If the page already contains

<img
    src="https://secure.gravatar.com/avatar/HASH"
>

the browser can request the avatar as soon as the page loads.

A banner appearing afterward does not undo that request

If your privacy architecture requires user choice before that third-party request, the avatar URL itself needs to be withheld or replaced until the appropriate trigger.

A simpler approach is often local avatars

Then there is no Gravatar resource to gate.

Technical prevention is cleaner than cosmetic consent

No external URL
↓
no external request

is easier to verify than:

external URL exists
↓
several scripts attempt
to prevent it conditionally.

Can Content Security Policy block Gravatar?

Yes, depending on the policy.

For example, a strict:

img-src 'self';

would block external Gravatar images.

But CSP is not an avatar replacement

The result may simply be:

broken avatar image

Replace the functionality deliberately

Then use CSP as an enforcement layer.

A privacy-friendly architecture might use

local avatar
+
local default placeholder
+
img-src 'self' data:

depending on the site’s wider asset requirements.

Does caching Gravatar locally help?

It can change the browser-side request path.

Instead of

every visitor
↓
Gravatar

you might implement:

WordPress server
↓
fetch Gravatar periodically
↓
cache image locally

visitor
↓
local cached image

This reduces direct visitor-to-Gravatar connections

But the WordPress server still communicates with Gravatar.

The email-derived identifier is still used for lookup

So this is different from:

fully local avatar upload.

Server-side proxying changes the privacy model

It does not eliminate every external relationship.

Choose according to your objective

Goal:
hide visitor IP from avatar provider
→ local proxy/cache may help

Goal:
eliminate Gravatar entirely
→ local avatar + local fallback

What about anonymizing the email before hashing?

You cannot simply change:

user@example.com

into some site-specific random value and still expect Gravatar to find the same account.

The service needs the standardized identifier

That is what links the email identity to the stored avatar.

Once you replace that identity system

you are effectively building a local avatar system.

This is why local avatars are conceptually cleaner

They stop trying to make a global email-based identity mechanism behave like a site-local identity mechanism.

How serious is the risk?

There is no universal severity level.

Risk depends on context

Factors include:

• whether the page is public;
• whether the person’s name is visible;
• whether their employer/domain is obvious;
• whether the same identifier appears elsewhere;
• whether comments are public;
• whether external avatar requests are acceptable in the site’s privacy model.

For a public technology blog

Authors may deliberately use global Gravatar profiles.

For a private mental-health portal or employee system

a cross-site email-derived avatar identity could be much less desirable.

Architecture should reflect context

There is no prize for maximizing external integrations.

Nor is there one for deleting useful functionality without analysis

A practical Gravatar privacy decision tree

Does the site need avatars?
│
├── No
│   └── Disable avatars
│
└── Yes
    │
    └── Does the site need
        global Gravatar identity?
        │
        ├── Yes
        │   └── Keep Gravatar,
        │       document and audit it
        │
        └── No
            │
            └── Use local avatars
                │
                └── Need zero
                    Gravatar requests?
                    │
                    ├── Yes
                    │   └── local avatar
                    │       +
                    │       local fallback
                    │
                    └── No
                        └── Gravatar can
                            remain fallback

A hash-risk decision tree

Public Gravatar hash
│
└── Can observer guess
    possible email?
    │
    ├── No
    │   └── difficult to
    │       associate directly
    │
    └── Yes
        │
        └── Hash candidate
            │
            ├── does not match
            │   └── try another
            │
            └── matches
                └── candidate
                    confirmed

A network-request decision tree

Avatar rendered
│
├── Local URL
│   └── visitor stays
│       on site infrastructure
│
└── Gravatar URL
    └── visitor browser
        contacts Gravatar
        │
        ├── avatar identifier
        └── network metadata

WordPress Gravatar privacy checklist

• Check whether avatars are enabled.
• Inspect frontend avatar URLs.
• Search page source for gravatar.com.
• Search the Network panel for Gravatar requests.
• Test registered users.
• Test guest commenters.
• Test users without Gravatar accounts.
• Test users without local avatars.
• Audit wp-admin separately.
• Check plugins using get_avatar().
• Search custom code for manually constructed Gravatar URLs.
• Remember current WordPress uses SHA-256 for generated Gravatar URLs.
• Do not describe current WordPress as universally exposing MD5 hashes.
• Do not claim the email is normally transmitted in plaintext in the avatar URL.
• Treat the deterministic hash as an email-derived identifier.
• Consider cross-site linkability.
• Consider whether likely email addresses can be guessed.
• Remember hashing is not encryption.
• Remember SHA-256 strength does not prevent candidate testing.
• Consider the visitor-to-Gravatar network request separately.
• Review applicable privacy requirements.
• Use local avatars if global Gravatar identity is unnecessary.
• Use a fully local fallback if the goal is zero Gravatar requests.
• Validate local avatar uploads securely.
• Do not put email addresses in local avatar filenames.
• Test the site after disabling Gravatar.
• Update the privacy policy to match actual behavior.

Common misconceptions about WordPress and Gravatar

“WordPress sends the user’s email address directly to Gravatar”

Current normal avatar URLs use a SHA-256 identifier derived from the normalized email, not the plain-text address.

“WordPress still uses MD5 for every Gravatar URL”

Outdated. WordPress 6.8 changed generated Gravatar URLs to SHA-256.

“SHA-256 means the email is anonymous”

No. The deterministic identifier can still be tested against likely email candidates.

“Someone can decrypt the SHA-256 hash”

That is the wrong model. The realistic concern is candidate generation and comparison, not ordinary cryptographic reversal.

“A stronger hash eliminates linkability”

No. The same email still generates the same standardized identifier.

“If the commenter has no Gravatar account, there is no request”

WordPress can still generate and request the Gravatar URL so that Gravatar can return the configured fallback.

“A default avatar means it is local”

Not necessarily. Inspect the actual image URL.

“HTTPS prevents Gravatar from seeing the request”

HTTPS protects data in transit. The destination server still receives the request.

“Disabling cookies solves the Gravatar privacy issue”

The external image request itself can still expose connection metadata.

“A consent banner automatically blocks Gravatar”

Only if the implementation actually prevents the avatar resource from loading before the relevant trigger.

“Installing local avatars automatically eliminates every Gravatar request”

Not if users without local images still fall back to Gravatar.

“Blocking gravatar.com with CSP is enough”

That may remove the external request but can leave broken avatar UI. Replace the functionality deliberately.

“Local avatars have no privacy considerations”

Profile photographs and stored user data still need proper handling.

Quick reference: what current WordPress does

INPUT

user@example.com


NORMALIZE

trim whitespace

lowercase


HASH

SHA-256


OUTPUT

https://secure.gravatar.com/
avatar/SHA256_HASH


BROWSER

requests avatar
from Gravatar

Quick reference: what changed

Older WordPress
→ MD5-based Gravatar IDs

WordPress 6.7+
→ Gravatar URLs forced to HTTPS

WordPress 6.8+
→ generated Gravatar IDs
  use SHA-256

Quick reference: privacy layers

LAYER 1

Email-derived identifier
appears in avatar URL


LAYER 2

Same identifier can appear
across multiple sites


LAYER 3

Candidate emails can be
hashed and compared


LAYER 4

Visitor browser contacts
external Gravatar infrastructure


LAYER 5

External service receives
standard request/network data

Related WordPress privacy and user guides

For the wider user-data, privacy and external-resource cluster, continue with:

• WordPress privacy and third-party requests
• Local Avatar
• WordPress user meta, explained
• WordPress user roles and capabilities, explained
• Auditing dormant WordPress user accounts
• CDN vs. self-hosted assets in WordPress
• Why Third-Party Embeds Slow Down WordPress
• Self-hosting Google Fonts in WordPress
• How to Disable oEmbed in WordPress

Final thoughts

Gravatar does not need to place a plain-text email address into the HTML to create a meaningful privacy consideration.

Current WordPress takes the email:

user@example.com

normalizes it and produces a deterministic SHA-256 identifier.

That identifier becomes part of a public Gravatar URL:

email
↓
SHA-256 identifier
↓
avatar URL

This creates two important properties.

First:

someone with a plausible
email candidate can hash it
and compare the result.

Second:

the same email generates
the same Gravatar identity
across participating sites.

Then there is the separate network layer:

visitor browser
↓
secure.gravatar.com

which means avatar rendering itself introduces an external request.

The right conclusion is therefore not:

Gravatar exposes every email
in plain text.

That would be inaccurate.

The more precise conclusion is:

Gravatar converts an email address
into a reproducible cross-site
identifier and uses external
infrastructure to resolve it.

Whether that tradeoff is acceptable depends on the website.

If global avatars are useful, keep Gravatar deliberately and document the architecture.

If global identity is unnecessary, TheOneWP Local Avatar can keep profile pictures inside WordPress and, when its Gravatar fallback is disabled, use a locally generated initials placeholder for users who have not uploaded a picture. The resulting avatar path stays local instead of requiring another Gravatar lookup. theonewp.WordPress.2026-08-18 (1).xml

The broader rule is simple:

Do not assume that
"hashed"
means
"anonymous."

Do not assume that
"just an image"
means
"no external data flow."

Once those two assumptions disappear, WordPress avatar privacy becomes much easier to reason about.