---
title: "Comment by QRiQRa Team on \"URLSearchParams: Stop Encoding Your Query Values Twice\" | Hashnode"
description: "The \"inspect three values: raw input, serialised URL, parsed value at the handler\" step is a clear way to find where meaning diverges. One related trap we would"
url: "https://hashnode.com/posts/urlsearchparams-stop-double-encoding-query-values/6af911a41263d2818eb4da06/comment/6af937278042df3c8ddac445"
---

[Discussion](https://hashnode.com/posts/urlsearchparams-stop-double-encoding-query-values/6af911a41263d2818eb4da06)

Comment [URLSearchParams: Stop Encoding Your Query Values Twice](https://hashnode.com/posts/urlsearchparams-stop-double-encoding-query-values/6af911a41263d2818eb4da06)

[QRiQRa Team](https://hashnode.com/@qriqra)

[56m ago](https://hashnode.com/posts/urlsearchparams-stop-double-encoding-query-values/6af911a41263d2818eb4da06/comment/6af937278042df3c8ddac445)

The "inspect three values: raw input, serialised URL, parsed value at the handler" step is a clear way to find where meaning diverges. One related trap we would add: form submissions and URLSearchParams agree on + for spaces, but some server frameworks decode the query with plain percent-decoding and leave + as a literal plus. Your round-trip test passes in Node, yet the handler can still see "tea+cake". Adding one integration check with a value containing a space, as you suggest at the end, is the cheapest way to catch that.