User changed their avatar in the mini program, but it turns back to the gray default image on another phone — is it because it wasn't saved on our own server?

Conclusion first: when a user has changed their avatar in a mini program but logs in on another phone and sees the gray default image again, in most cases the platform did not delete the image. The avatar was only stored as a temporary path, not transferred to your own storage, or only written to local cache. By 2026, platforms no longer return the real avatar and nickname directly through a single authorization. The common approach is to use the avatar and nickname input capability: use button open-type=chooseAvatar for the avatar and input type=nickname for the nickname. After obtaining the temporary file, upload it immediately to your own object storage, then save the stable URL to the database. If you only call the old API, it may look fine in the developer tools, but on a real device you will get anonymous information.

Why does the avatar revert to gray after the user has filled it in and switches devices?

This is not because the API is broken. It is because two things are mixed together: the platform returns anonymous information in the first place, and the avatar temporary path expires. To protect account profile data, the platform has gradually withdrawn the ability to read the real avatar and nickname directly through a single authorization. The avatar becomes a uniform gray placeholder, and the nickname becomes “WeChat User”. The code call succeeds, but the value returned is anonymous. Another common cause is that after the user selects an avatar, the program stores the temporary path in the database. The temporary path has an expiration time, so it becomes invalid the next day or when viewed on another device.

There is a simple way to tell the direction: run the same code in the developer tools and on a real device. If the developer tools show a custom avatar but the real device shows gray, or a newly registered WeChat account behaves the same as an old one, it is basically the platform returning anonymous information. If both the developer tools and the real device work normally, and it only fails after a day or two or after switching phones, it is more likely that the temporary path was not transferred. Common signs:

• The authorization popup appears normally, the user taps allow, but the returned avatarUrl is the default gray placeholder;
• The nickname field returns “WeChat User”, not the name the user set;
• Try again with a WeChat account that has never authorized, and the result is the same;
• The avatar displays right after being filled in, but turns gray the next day or on another device.

Three common ways to obtain and store avatars and nicknames in 2026, and who each one suits

Since you cannot get the data directly through a single authorization, you need to separate “user identity” from “user profile”. Identity relies on the login state, using code to exchange for openid. The profile needs to be filled in by the user. In 2026 project delivery, there are three common paths: the avatar and nickname input capability, a self-built profile page in the backend, and using the open platform unionid to link existing profile data. They are not substitutes for each other; it depends on your existing users, platform coverage, and schedule.

Path A: Avatar and nickname input capability. The platform provides button open-type=chooseAvatar for the user to choose an avatar, and input type=nickname for the user to confirm the nickname. The advantage is a short interaction flow that follows platform rules. Note that what you get is a temporary file path. You must upload it to your own storage immediately; otherwise the avatar will not display after the link expires.

Path B: Self-built upload and input in the backend. The user selects an image from the album to upload and enters a nickname, and the server stores it uniformly. Controllability is high, suitable for multi-platform products that also need to support App and H5. The cost is one extra interaction step, and you need to handle image compression, size cropping, and nickname sensitive words yourself.

Path C: Open platform unionid linking existing profile data. If the company already has an official account or another user system and the user has authorized before, you can link the existing avatar and nickname through unionid. Suitable for businesses with many existing users, but new users still need to first two paths, so it cannot be a general solution.

The differences among the three paths can be quickly compared on the following dimensions (experience ranges for reference; actual values vary by project):

• Interaction cost: Path A is usually 1-2 steps; Path B is commonly 3-4 steps; Path C depends on the proportion of existing users.
• Compliance fit: Path A has a relatively high fit with platform rules; Path B requires you to write clear privacy statements and purposes.
• Development effort (experience range): Path A is about 0.5-1 person-day; Path B is about 1-2 person-days; Path C depends on the existing system, with a typical range of 1-3 person-days.
• Who it suits: Path A suits most mini programs; Path B suits unified profiles across multiple platforms; Path C suits products with a large number of existing authorized users.

How to check before delivery: entry, collection, and storage layers

To avoid discovering after launch that avatars do not display or nicknames are abnormal, we usually check on three layers: entry layer, collection layer, and storage layer. The reason for this division is that whether the authorization entry is correct, whether the data obtained is clean, and whether what is stored can be accessed long-term are three independent things. Mixing them together makes troubleshooting prone to back-and-forth changes.

1. Entry layer: Confirm the button and input box use the platform-recommended components. The user should be able to trigger them again after refusing, and you should not treat mandatory authorization as a prerequisite for proceeding.
2. Collection layer: After obtaining the avatar temporary path, immediately validate the file format and size. Handle nickname length, emoji, and sensitive words, and provide a fallback default for empty values.
3. Storage layer: Upload the temporary file to your own object storage or cloud storage, and save your own URL to the database instead of the temporary path. Also consider image cropping and access acceleration.

What counts as qualified for each layer: the entry layer must be able to trigger again after the user refuses; the collection layer must not throw errors for empty values, overly long values, or special characters; the storage layer must still display the avatar correctly after switching devices or opening it the next day. Run through all three layers before handing off to testing, and you can reduce a lot of back-and-forth. A note from the delivery site: there was once a two-week project where the product requirement said “the user can get their WeChat avatar and nickname with one tap”. The developers implemented it according to old documentation. During integration, it looked normal in the developer tools, but on real-device testing all new users had gray avatars. Before launch, they found they needed to add a profile confirmation page, which required changes from frontend, backend, and design. Based on typical ranges, rework was about 2-3 days, and the schedule slipped. Later, they confirmed which path to use during requirement review, which kept this kind of change under control.

Applicable and non-applicable boundaries

Scenarios that need user identity and content ownership are suitable for avatars and nicknames, such as community posts, review photos, group-buy displays, and order contacts. When users need to present themselves and you need to distinguish content ownership, avatars and nicknames can improve credibility and browsing experience. Conversely, purely tool-based, internal-use, anonymous voting, or content-only products do not need to force users to fill in avatars and nicknames. Forced authorization instead increases churn.

• Suitable: Community, reviews, group buying, second-hand trading, and other scenarios with content ownership; multiple roles or accounts that need to distinguish operators; customer service that needs to identify a user's historical orders or tickets.
• Not necessary: Anonymous questionnaires, internal tools, purely display pages; scenarios where users come only once and do not accumulate profile data; scenarios where mandatory profile filling would block the core flow.

The boundary can be remembered this way: if the product only displays and queries, does not involve user-generated content, and does not need content ownership, avatar and nickname acquisition can be skipped. If you do implement it, also allow users to skip, rather than making profile filling a hard threshold.

FAQ

Can mini programs still use the old API to get the real avatar and nickname?

By 2026, the common result is that only anonymous information is returned: the avatar is the default gray image and the nickname is “WeChat User”. Real profile data depends on the avatar and nickname input capability or the user uploading it themselves.

Can the avatar address obtained from the avatar and nickname input capability be stored directly in the database?

Usually not recommended. What you get is a temporary path that cannot be accessed after expiration. Upload it to your own object storage first, then save the stable URL to the database.

After a user refuses authorization, can we still ask them to fill in avatar and nickname?

Yes, but make the entry a regular button or profile page, not just a one-time popup at startup. After the user refuses, they should still be able to trigger it again when they return.

Does not implementing avatar and nickname affect mini program review?

Generally there is no hard requirement. But if the category or page already promises social or review features, incomplete profile display may require supplementary explanation. Specifics depend on platform rules and review feedback.

If your mini program has already hit the gray avatar problem, first check the three layers: entry, collection, and storage. Then decide whether to add a profile page or change the interaction. It suits products that need user identity and content ownership. If you only do query and display and users do not generate content, you can launch first with default avatars and a unified nickname, and add it when the business needs it. For specific APIs and component usage, refer to the official documentation of the relevant platform.