In 2026, when two Uni-app pages are integrated, one says it passed an object and the other says it received a string—which one should you trust?

When a Uni-app page navigation passes an object, but the receiving page's onLoad gets a string, this is usually not a broken framework. Instead, the URL parameter mechanism itself only carries strings. APIs such as uni.navigateTo and uni.redirectTo append parameters to the path query. Non-string values are usually serialized, and the receiving side needs to deserialize them according to an agreed convention. Otherwise, you get a value that 'looks like an object but is actually a string.' In 2026 multi-platform delivery, this issue behaves slightly differently on H5, mini programs, and App, but the root cause is the same.

What does URL parameter passing actually do to an object?

In Uni-app cross-platform development, a common way to pass parameters during page navigation is to build a URL. Mini program, App, and H5 ends all eventually turn parameters into a path string; the difference is only in serialization details. Reference types such as objects and arrays are not passed as-is. Some platforms implicitly call toString and produce [object Object], while others keep a JSON shape but it is still a string. So the receiving page first sees a string, and if it wants to use it as an object, it needs to JSON.parse it itself.

The way to check is direct: in the target page's onLoad, print typeof options.xxx and the raw value; do not guess by eye. If you are passing a simple id or status flag, you can use it directly. If you are passing an object, explicitly JSON.stringify before sending, explicitly JSON.parse after receiving, and wrap the parsing in try/catch to avoid a blank page caused by an abnormal parameter.

• Core conclusion: URL query only accepts strings; objects are usually serialized, and the receiving side is responsible for deserialization.
• Multi-platform differences: Different platforms handle special characters, length limits, and encoding differently; do not rely on implicit conversion.
• Acceptance criteria: The type received by the target page matches what was sent, missing parameters have fallbacks, and parsing failures do not cause a blank page.

Which parameters are suitable for the URL, and which should not be forced in?

URL parameter passing is intuitive, shareable, and back-button friendly, making it suitable for simple, non-sensitive, small data. For example, going from a list page to a detail page with a product id, or from a campaign page to a form page with a source tag. These scenarios pass only one or a few short fields, behave consistently across platforms, and are easy to debug. A common 2026 practice is to treat URL parameters as a 'page identity card,' not a 'data moving truck.'

Conversely, stuffing full objects, long text, image base64, or user tokens into the URL easily causes problems. Mini program platforms and some App containers have an experience range limit on URL length; the typical range is that beyond one or two thousand characters, truncation or platform differences may occur. On H5, an overly long link is also bad for sharing and analytics. A safer approach is to pass only an identifier, and let the receiving page re-request by that identifier or read from cache.

• Suitable: ids, type tags, source channels, simple filter conditions, short status codes.
• Not suitable: large objects, sensitive information, binary data, data that must survive a refresh.
• Boundary: If you find that you need to pass more than three to five fields, or a field value itself exceeds a few dozen characters, prioritize changing the parameter-passing method.

How to decide the parameter-passing method—a 'four questions' decision order

Rather than agonizing each time over which method to use, fix a decision order. The 'four parameter-passing questions' below come from project delivery conventions. Ask them in order, and you can basically settle on a plan. Its value is turning 'can it be passed?' into 'should it be passed?' and reducing blame-shifting during integration.

1. Ask about data size: Is it only an id or a few short fields? Use the URL. Many fields or long values? Move to the next question.
2. Ask about lifecycle: Is it used only in the current navigation chain and discarded on return? Global state or an event bus can work. Does it need to survive refresh or app restart? Use local storage.
3. Ask about real-time needs: Does the receiving page need to immediately reflect the latest value from the sending page? Use global state or state management to avoid an outdated URL snapshot.
4. Ask about sensitivity: Does it include tokens, phone numbers, or internal state? Do not put it in the URL. Re-fetch by id through an API, or keep it in memory and clear it on leave.

Each step has different cautions: URL parameters need attention to encoding and length; global state needs attention to whether the page re-reads it on return; local storage needs attention to key naming conventions and cleanup timing; re-fetching from an API needs attention to loading and failure fallbacks. Put these four questions in the project specification so even newcomers can choose by the same standard.

On the delivery floor: an integration that was reworked because of the parameter-passing method

A common project situation: the timeline is tight and multiple platforms are being developed in parallel. To save effort, a frontend developer JSON.stringify's an entire filter-condition object and stuffs it into the URL. Everything works in the development environment. Then in the test environment, the H5 share link gets long, the mini program end occasionally truncates it, and the receiving page shows a blank screen after parsing fails. The client reports it three days before acceptance, and the team can only go back and change the parameter-passing convention: simple filters go through the URL, complex conditions go through global state plus local cache, and the receiving page uniformly provides parsing fallback. As a result, they spend an extra regression round, but also lock down the parameter-passing standard for later pages.

According to project delivery habits, such issues should be agreed upon before integration: which parameters go through the URL, which go through state, and which must be re-requested. Write the convention in the API document or frontend specification; it saves trouble compared with firefighting afterward. The constraint is that both budget and timeline are limited. The approach is to first run through the four-question framework. The cost is an extra half hour of alignment up front, and the benefit is avoiding one round of rework. A common experience range is that spending an extra 0.5–1 hour on alignment up front can reduce one round of integration rework by half a day to a day.

Common questions

When uni.navigateTo passes an object, what should I do if the receiving page throws an error on JSON.parse?

First confirm whether the sending side used encodeURIComponent and whether the string contains unescaped special characters. On the receiving side, wrap parse in try/catch; on failure, provide a default value or fall back to the list page instead of showing a blank screen.

When passing parameters through global state, why is the data not updated after returning to the previous page?

Global state stores a reference, but the page may not re-read it. You can read it again in onShow, or have state changes trigger a subscription. If the interface still shows old values after returning, first check whether the lifecycle contains refresh logic.

Do Uni-app's H5 and WeChat Mini Program ends behave the same when passing parameters?

The underlying mechanism is URL query on both, but encoding, length limits, and routing behavior differ. A common practice is for the sending side to always serialize explicitly and the receiving side to always deserialize explicitly; do not rely on implicit conversion on any particular platform.

If parameters contain Chinese characters or special symbols and become garbled when passed, what should I do?

Use encodeURIComponent before sending and decodeURIComponent after receiving. If the link also needs to be shared externally, it is better to pass only an id, and have the receiving page re-request the Chinese content by id.

For passing a large object, should I use the URL or local cache? How should I choose?

Large objects are not recommended in the URL. If they are used only in the current session, put them in global state. If they need to survive across pages or refreshes, put them in local cache, and agree on key names and cleanup timing to avoid stale data lingering.

Action guide: Before the next page navigation, first use the 'four parameter-passing questions' to judge data size, lifecycle, real-time needs, and sensitivity, then decide whether to use the URL, global state, or local cache. Applicable boundaries: Simple short fields and non-sensitive data are suitable for the URL; large objects, sensitive information, and data that must survive refresh are more stable through state or storage. In 2026 multi-platform delivery, writing parameter-passing conventions into frontend agreements saves time compared with troubleshooting afterward.