[GH-ISSUE #2227] [feature]: Syncing query parameters in URL and query parameter input

kerem commented

2026-03-16 17:04:39 +03:00

Owner

Originally created by @FidalMathew on GitHub (Apr 2, 2022).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/2227

Is there an existing issue for this?

I have searched the existing issues

Summary

When we add query parameters in the query parameters input, it does not show any change in URL and visa versa.

Case 1:
Parameters in URL but not in Query Parameters:

Case 2:
Key-value pair in Query Parameter but not in URL:

New feature:

Why should this be worked on?

Syncing the URL and query parameters will help the developer to get a clear understanding of how query parameters work. Moreover, it helps identify all query parameters being used in a single glance.

Originally created by @FidalMathew on GitHub (Apr 2, 2022). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/2227 ### Is there an existing issue for this? - [X] I have searched the existing issues ### Summary When we add query parameters in the query parameters input, it does not show any change in URL and visa versa. **Case 1:** Parameters in URL but not in Query Parameters: ![image](https://user-images.githubusercontent.com/84982038/161370443-dfa4701d-a096-46b5-b4a6-e4da33ca8a16.png) **Case 2:** Key-value pair in Query Parameter but not in URL: ![image](https://user-images.githubusercontent.com/84982038/161370531-5b6fab03-7cc3-4859-b77a-8ea0a5ad203a.png) **New feature:** ![image](https://user-images.githubusercontent.com/84982038/161370585-d1caed74-51eb-452a-a5f7-2c6b7d75fe34.png) ### Why should this be worked on? Syncing the URL and query parameters will help the developer to get a clear understanding of how query parameters work. Moreover, it helps identify all query parameters being used in a single glance.

kerem added the

feature

label

2026-03-16 17:04:39 +03:00

kerem commented

2026-03-16 17:04:50 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Apr 2, 2022):

This is a design decision we chose to take. We have seen that for long parameter chains, the effect of the parameters being on the URL is detrimental to the readability of the URL compared to the separated parameters.

We will keep the issue for a while to poll opinions on whether we have to rollback though.

@AndrewBastin commented on GitHub (Apr 2, 2022): This is a design decision we chose to take. We have seen that for long parameter chains, the effect of the parameters being on the URL is detrimental to the readability of the URL compared to the separated parameters. We will keep the issue for a while to poll opinions on whether we have to rollback though.

kerem commented

2026-03-16 17:04:55 +03:00

Author

Owner

@KartikSoneji commented on GitHub (Jul 8, 2022):

Allowing parameters to be defined in two places (url and the parameters tab) is both inconsistent and can lead to unexpected and hard to find bugs, especially in urls with many parameters.

Maybe there can be a button to toggle between the expanded and unexpanded url?

Case in point:

As a side note, maybe duplicate parameters can have a visual indicator (and a warning) to show they are duplicates?
Not all framworks support repeated query parameters, some only read the first or last value while others require the name be suffixed by [] (eg: a[]=0&a[]=1).

@KartikSoneji commented on GitHub (Jul 8, 2022): Allowing parameters to be defined in two places (url and the parameters tab) is both inconsistent and can lead to unexpected and hard to find bugs, _especially_ in urls with many parameters. Maybe there can be a button to toggle between the expanded and unexpanded url? Case in point: ![image](https://user-images.githubusercontent.com/25801283/178004155-4b068d7c-dbd2-44ec-8c0e-ad537e8c17b2.png) As a side note, maybe duplicate parameters can have a visual indicator (and a warning) to show they are duplicates? Not all framworks support repeated query parameters, some only read the first or last value while others require the name be suffixed by `[]` (eg: `a[]=0&a[]=1`).

kerem commented

2026-03-16 17:05:00 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Jul 13, 2022):

A button to move things back and forth of the variable from URLs is something we can consider as a compromise.
But we are still going to keep this behaviour of having parameters in both the places independently to keep the URL area more cleaner.

As a side note, maybe duplicate parameters can have a visual indicator (and a warning) to show they are duplicates?
Not all framworks support repeated query parameters, some only read the first or last value while others require the name be suffixed by [] (eg: a[]=0&a[]=1).

The visual indicator idea won't work and you have provided the reason yourself why not yourself, it is not explicitly disallowed by the spec (See: https://stackoverflow.com/a/24728298). Hence we cannot add an indicator.

Keeping this open for review/reconsideration for later.

@AndrewBastin commented on GitHub (Jul 13, 2022): A button to move things back and forth of the variable from URLs is something we can consider as a compromise. But we are still going to keep this behaviour of having parameters in both the places independently to keep the URL area more cleaner. > As a side note, maybe duplicate parameters can have a visual indicator (and a warning) to show they are duplicates? Not all framworks support repeated query parameters, some only read the first or last value while others require the name be suffixed by [] (eg: a[]=0&a[]=1). The visual indicator idea won't work and you have provided the reason yourself why not yourself, it is not explicitly disallowed by the spec (See: https://stackoverflow.com/a/24728298). Hence we cannot add an indicator. Keeping this open for review/reconsideration for later.

kerem commented

2026-03-16 17:05:05 +03:00

Author

Owner

@KartikSoneji commented on GitHub (Jul 13, 2022):

But we are still going to keep this behaviour of having parameters in both the places independently to keep the URL area more cleaner.

Sorry I didn't get this.
Adding url parameters in both places is confusing.
How is that better than having a toggle?

The visual indicator idea won't work and you have provided the reason yourself why not yourself, it is not explicitly disallowed by the spec (See: https://stackoverflow.com/a/24728298). Hence we cannot add an indicator.

We can add an indicator with a tooltip to warn users, just so they know the potential issues.
It won't prevent users from making the request.

@KartikSoneji commented on GitHub (Jul 13, 2022): > But we are still going to keep this behaviour of having parameters in both the places independently to keep the URL area more cleaner. Sorry I didn't get this. Adding url parameters in both places is confusing. How is that better than having a toggle? <br> > The visual indicator idea won't work and you have provided the reason yourself why not yourself, it is not explicitly disallowed by the spec (See: https://stackoverflow.com/a/24728298). Hence we cannot add an indicator. We can add an indicator with a tooltip to warn users, just so they know the potential issues. It won't prevent users from making the request.

kerem commented

2026-03-16 17:05:10 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Jul 14, 2022):

Adding url parameters in both places is confusing.
How is that better than having a toggle?

As I said, I am looking to a compromise where we will be adding a separate section to the Parameters list that shows the things inferred from the URL (Similar to how we have inferred headers in the Headers section), along with that we can add an option to move the parameter to and from the URL or the parameter list.

The main idea behind that isolation of Parameters to a separate section is to keep the URL area clean, although a toggle can allow the other part to be hidden, it is not a fully complete solution, for example, certain query parameters are pretty constant and have a quality of being like a part of the URL itself. Those are better to be in the URL. Parameters section is more meant for things that can change frequently or have a need to be isolated as a value that can be modified.

Now as to how confusing that is, I don't really think so. One thing to note is, this issue has been open for a while now and there has been no echos for support for this to be implemented in the app. It is an isolated concern that you are having. Along with that other alternatives (for example, Insomnia), also keep the same behavior where they don't sync up like that.
So there is already a precedent that has been set.

We can add an indicator with a tooltip to warn users, just so they know the potential issues.
It won't prevent users from making the request.

Again, the spec doesn't disallow it. Hence we are not going to add any sort of warning there. We have even instances where there are APIs that work against the HTTP spec (like the Elasticsearch REST API). We do not want to create extra noise in the UI just for some warnings.

Our plan with warnings is only for cases where we can't technically make the request according to the user's will. For example like with the aforementioned Elasticsearch REST API, which want the GET request to have a request body (completely against the HTTP spec). We want to implement a warning there because it is against the spec and we cannot actually send a body from the browser for a GET request anyways.

@AndrewBastin commented on GitHub (Jul 14, 2022): > Adding url parameters in both places is confusing. How is that better than having a toggle? As I said, I am looking to a compromise where we will be adding a separate section to the Parameters list that shows the things inferred from the URL (Similar to how we have inferred headers in the Headers section), along with that we can add an option to move the parameter to and from the URL or the parameter list. The main idea behind that isolation of Parameters to a separate section is to keep the URL area clean, although a toggle can allow the other part to be hidden, it is not a fully complete solution, for example, certain query parameters are pretty constant and have a quality of being like a part of the URL itself. Those are better to be in the URL. Parameters section is more meant for things that can change frequently or have a need to be isolated as a value that can be modified. Now as to how confusing that is, I don't really think so. One thing to note is, this issue has been open for a while now and there has been no echos for support for this to be implemented in the app. It is an isolated concern that you are having. Along with that other alternatives (for example, Insomnia), also keep the same behavior where they don't sync up like that. So there is already a precedent that has been set. > We can add an indicator with a tooltip to warn users, just so they know the potential issues. It won't prevent users from making the request. Again, the spec doesn't disallow it. Hence we are not going to add any sort of warning there. We have even instances where there are APIs that work against the HTTP spec (like the Elasticsearch REST API). We do not want to create extra noise in the UI just for some warnings. Our plan with warnings is only for cases where we can't technically make the request according to the user's will. For example like with the aforementioned Elasticsearch REST API, which want the GET request to have a request body (completely against the HTTP spec). We want to implement a warning there because it is against the spec and we cannot actually send a body from the browser for a GET request anyways.

kerem commented

2026-03-16 17:05:15 +03:00

Author

Owner

@jtleathers commented on GitHub (May 17, 2023):

Clearly I am in the minority here based on the lack for responses but I tried switching from Postman to Hoppscotch and the implementation of parameters here is a deal breaker for me.

To me, the purpose of the parameter fields is as an interface to build the URL. Unfortunately, Hoppscotch doesn't display this final result anywhere easy to access. You can find the URL in "Show code" mixed in with other code or the "Headers" tab, though even there it is not always accurate I've found.

If Hoppscotch implements some toggle to be able to show/hide the URL with all parameters I would gladly switch over to using it.

@jtleathers commented on GitHub (May 17, 2023): Clearly I am in the minority here based on the lack for responses but I tried switching from Postman to Hoppscotch and the implementation of parameters here is a deal breaker for me. To me, the purpose of the parameter fields is as an interface to build the URL. Unfortunately, Hoppscotch doesn't display this final result anywhere easy to access. You can find the URL in "Show code" mixed in with other code or the "Headers" tab, though even there it is not always accurate I've found. If Hoppscotch implements some toggle to be able to show/hide the URL with all parameters I would gladly switch over to using it.

kerem commented

2026-03-16 17:05:21 +03:00

Author

Owner

@me-nkr commented on GitHub (Jun 10, 2023):

Along with that other alternatives (for example, Insomnia), also keep the same behavior where they don't sync up like that.

Although, Insomnia has a URL preview that shows a URL with all the query parameters.

@me-nkr commented on GitHub (Jun 10, 2023): > Along with that other alternatives (for example, Insomnia), also keep the same behavior where they don't sync up like that. Although, Insomnia has a URL preview that shows a URL with all the query parameters.

kerem commented

2026-03-16 17:05:26 +03:00

Author

Owner

@duerrm commented on GitHub (Jul 27, 2023):

Clearly I am in the minority here based on the lack for responses but I tried switching from Postman to Hoppscotch and the implementation of parameters here is a deal breaker for me.

To me, the purpose of the parameter fields is as an interface to build the URL. Unfortunately, Hoppscotch doesn't display this final result anywhere easy to access. You can find the URL in "Show code" mixed in with other code or the "Headers" tab, though even there it is not always accurate I've found.

If Hoppscotch implements some toggle to be able to show/hide the URL with all parameters I would gladly switch over to using it.

Same for me. Would be very happy about a configuration option to en-/disable the parameter sync.

@duerrm commented on GitHub (Jul 27, 2023): > Clearly I am in the minority here based on the lack for responses but I tried switching from Postman to Hoppscotch and the implementation of parameters here is a deal breaker for me. > > To me, the purpose of the parameter fields is as an interface to build the URL. Unfortunately, Hoppscotch doesn't display this final result anywhere easy to access. You can find the URL in "Show code" mixed in with other code or the "Headers" tab, though even there it is not always accurate I've found. > > If Hoppscotch implements some toggle to be able to show/hide the URL with all parameters I would gladly switch over to using it. Same for me. Would be very happy about a configuration option to en-/disable the parameter sync.

kerem commented

2026-03-16 17:05:31 +03:00

Author

Owner

@MaRmARk0 commented on GitHub (Dec 12, 2023):

@duerrm you're not a minority. This is dealbreaker for me also. I'm a developer designing an API and for example now I tried to switch from Insomnia to HoppScotch, but the lack of conversion from Parameters tab into query-string is kinda weird. It's simple to do and e.g. I cannot simply copy full GET URL with 11 parameters nor can I see it anywhere. If there was some Request log or at least something where I could see full constructed GET URL with all the params... ach.

Yes I can open developer tools (F12) and copy it from there but c-mon guys, can't you just add some URL Preview button which will show fully constructed URL just for sake of copy-pasting it?

@MaRmARk0 commented on GitHub (Dec 12, 2023): @duerrm you're not a minority. This is dealbreaker for me also. I'm a developer designing an API and for example now I tried to switch from Insomnia to HoppScotch, but the lack of conversion from Parameters tab into query-string is kinda weird. It's simple to do and e.g. I cannot simply copy full GET URL with 11 parameters nor can I see it anywhere. If there was some Request log or at least _something_ where I could see full constructed GET URL with all the params... ach. Yes I can open developer tools (F12) and copy it from there but c-mon guys, can't you just add some `URL Preview` button which will show fully constructed URL just for sake of copy-pasting it?

kerem commented

2026-03-16 17:05:36 +03:00

Author

Owner

@liyasthomas commented on GitHub (Dec 12, 2023):

Hoppscotch can send URL query parameters to the Parameters section by selecting the URL text. Does this work for you?

screenity copy.webm

Also to view the URL preview, there's another feature that allows you to preview the entire request setup.
Does this help you?

screenity.webm

@liyasthomas commented on GitHub (Dec 12, 2023): Hoppscotch can send URL query parameters to the Parameters section by selecting the URL text. Does this work for you? [screenity copy.webm](https://github.com/hoppscotch/hoppscotch/assets/10395817/ea0a84c9-5a1c-4be8-822a-2cc7302b0929) Also to view the URL preview, there's another feature that allows you to preview the entire request setup. Does this help you? [screenity.webm](https://github.com/hoppscotch/hoppscotch/assets/10395817/78abe140-11dc-4db2-9934-77ee9043a122)

kerem commented

2026-03-16 17:05:41 +03:00

Author

Owner

@MaRmARk0 commented on GitHub (Dec 12, 2023):

Sorry @liyasthomas those images weren't probably uploaded correctly.

I need to preview URL including query parameters so I can copy&paste it e.g. into Slack or wherever
https://i.imgur.com/97h6uGm.png

@MaRmARk0 commented on GitHub (Dec 12, 2023): Sorry @liyasthomas those images weren't probably uploaded correctly. I need to preview URL including query parameters so I can copy&paste it e.g. into Slack or wherever https://i.imgur.com/97h6uGm.png

kerem commented

2026-03-16 17:05:46 +03:00

Author

Owner

@liyasthomas commented on GitHub (Dec 12, 2023):

I've reuploaded the assets. Can you check @MaRmARk0?

@liyasthomas commented on GitHub (Dec 12, 2023): I've reuploaded the assets. Can you check @MaRmARk0?

kerem commented

2026-03-16 17:05:51 +03:00

Author

Owner

@MaRmARk0 commented on GitHub (Dec 12, 2023):

Oh, this should be documented more. I'd never imagine Show code would show something like this. To be honest it was the only submenu item I did not click on.

This should do the work. Thanks :)

@MaRmARk0 commented on GitHub (Dec 12, 2023): Oh, this should be documented more. I'd never imagine _Show code_ would show something like this. To be honest it was the only submenu item I did not click on. This should do the work. Thanks :)

kerem commented

2026-03-16 17:05:56 +03:00

Author

Owner

@liyasthomas commented on GitHub (Dec 12, 2023):

Sorry for making it difficult to discover this feature. We will improve the design to be more intuitive going forward.

Meanwhile, I've added the feature to the documentation: Snippets

@liyasthomas commented on GitHub (Dec 12, 2023): Sorry for making it difficult to discover this feature. We will improve the design to be more intuitive going forward. Meanwhile, I've added the feature to the documentation: [Snippets](https://docs.hoppscotch.io/documentation/features/snippets)

kerem commented

2026-03-16 17:06:01 +03:00

Author

Owner

@chimit commented on GitHub (Apr 11, 2024):

the parameter fields is as an interface to build the URL

Absolutely agree with @jtleathers. It's very hard to keep track of currently active GET parameters. The only way is to check green checkboxes. When you have dozens of params you can't even see all of them without scrolling.

@chimit commented on GitHub (Apr 11, 2024): > the parameter fields is as an interface to build the URL Absolutely agree with @jtleathers. It's very hard to keep track of currently active GET parameters. The only way is to check green checkboxes. When you have dozens of params you can't even see all of them without scrolling.

kerem commented

2026-03-16 17:06:06 +03:00

Author

Owner

@maxgalbu commented on GitHub (Jun 12, 2024):

Clearly I am in the minority here

@jtleathers add me to the minority who agrees with you

@maxgalbu commented on GitHub (Jun 12, 2024): > Clearly I am in the minority here @jtleathers add me to the minority who agrees with you

kerem commented

2026-03-16 17:06:11 +03:00

Author

Owner

@oonil commented on GitHub (Jan 23, 2025):

Clearly I am in the minority here based on the lack for responses but I tried switching from Postman to Hoppscotch and the implementation of parameters here is a deal breaker for me.

@jtleathers
same having :paramName is good way to directly add in parameter list instead of changing url for every request.

@oonil commented on GitHub (Jan 23, 2025): > Clearly I am in the minority here based on the lack for responses but I tried switching from Postman to Hoppscotch and the implementation of parameters here is a deal breaker for me. @jtleathers same having :paramName is good way to directly add in parameter list instead of changing url for every request.

kerem commented

2026-03-16 17:06:17 +03:00

Author

Owner

@ozzyrys commented on GitHub (Mar 4, 2025):

I know this topic is quite old but still relevant years later. My company and I were looking to migrate from Postman but lack of this feature is a deal breaker and now we have to look elsewhere.

We need to see query params in, you know, query. It's a very simple use case: I need to see query params, request body and response body all at once. Switching between tabs just to see my request in full is just a no go.

@ozzyrys commented on GitHub (Mar 4, 2025): I know this topic is quite old but still relevant years later. My company and I were looking to migrate from Postman but lack of this feature is a deal breaker and now we have to look elsewhere. We need to see query params in, you know, query. It's a very simple use case: I need to see query params, request body and response body all at once. Switching between tabs just to see my request in full is just a no go.

kerem commented

2026-03-16 17:06:22 +03:00

Author

Owner

@liyasthomas commented on GitHub (Mar 4, 2025):

@ozzyrys you can make use of the HTTP 1.1 Request String format mode from code generation to visualize the current active request setup at once.

@liyasthomas commented on GitHub (Mar 4, 2025): @ozzyrys you can make use of the HTTP 1.1 Request String format mode from code generation to visualize the current active request setup at once. <img width="1470" alt="Image" src="https://github.com/user-attachments/assets/847281cc-ae77-4d82-831a-ae5f6c5568fb" />

kerem commented

2026-03-16 17:06:27 +03:00

Author

Owner

@iscle commented on GitHub (Jun 6, 2025):

I just arrived here thinking this was a bug (coming from Postman) but I see this is the expected behavior.

As other people say, this is very confusing, especially for those coming from Postman.

I don't see the reason to not have the url box show the query parameters too. They are part of the URL spec, so not having it shown in there would be considered an error in my book.

Also, if some query parameter is too long does not matter, since they are always at the end of the url anyway. The beginning of the url would be shown either way.
If both the url box and the parameter tab are synced, it would be less confusing and better for ANY users to check what actual parameters are being sent, without having to scroll the url manually in case they, for example, copy pasted a url with the query parameters already there (something I do often). It would also be easier to see if a parameter is duplicated (which can happen during development) or has a typo, etc.

This is breaking the SST principle...

@iscle commented on GitHub (Jun 6, 2025): I just arrived here thinking this was a bug (coming from Postman) but I see this is the expected behavior. As other people say, this is very confusing, especially for those coming from Postman. I don't see the reason to not have the url box show the query parameters too. They are part of the URL spec, so not having it shown in there would be considered an error in my book. Also, if some query parameter is too long does not matter, since they are always at the end of the url anyway. The beginning of the url would be shown either way. If both the url box and the parameter tab are synced, it would be less confusing and better for ANY users to check what actual parameters are being sent, without having to scroll the url manually in case they, for example, copy pasted a url with the query parameters already there (something I do often). It would also be easier to see if a parameter is duplicated (which can happen during development) or has a typo, etc. This is breaking the SST principle...

kerem commented

2026-03-16 17:06:32 +03:00

Author

Owner

@gopi-ar commented on GitHub (Sep 5, 2025):

can make use of the HTTP 1.1 Request String format mode from code generation to visualize the current active request setup at once.

That workaround helps, but it doesn't solve the main issue. Our team wants to switch to Hoppscotch but can't because copying GET requests from browsers is such a pain..

Right now, to get a complete URL with params, we have to:

click code generation
select HTTP request format
copy hostname
copy request URI

Compare that to any browser where you just copy the URL field. It's the difference between 1 step and 4 steps for something developers do constantly.

@liyasthomas would you be open to a PR that syncs the URL field with the params section? This would make adoption so much easier for teams that frequently work with parameterized URLs.

@gopi-ar commented on GitHub (Sep 5, 2025): > can make use of the HTTP 1.1 Request String format mode from code generation to visualize the current active request setup at once. That workaround helps, but it doesn't solve the main issue. Our team wants to switch to Hoppscotch but can't because copying GET requests from browsers is such a pain.. Right now, to get a complete URL with params, we have to: 1. click code generation 2. select HTTP request format 3. copy hostname 4. copy request URI Compare that to any browser where you just copy the URL field. It's the difference between 1 step and 4 steps for something developers do constantly. @liyasthomas would you be open to a PR that syncs the URL field with the params section? This would make adoption so much easier for teams that frequently work with parameterized URLs.

kerem commented

2026-03-16 17:06:37 +03:00

Author

Owner

@21307369 commented on GitHub (Dec 2, 2025):

@ozzyrys
Some of the parameters of my request scripts, such as the order number timestamp, signature, etc., cannot be displayed here. My script is as follows:


import CryptoJS from 'https://esm.sh/crypto-js@4.2.0';
let key = pw.env.get("apikey").toString();
let mchId = pw.env.get("sysid").toString();
const timestamp = Date.now().toString(); 
const randomNum = Math.floor(Math.random() * 1000000)
    .toString()
    .padStart(8, '0'); 
const orderId = timestamp + randomNum; 

let queryParams = {};

hopp.request.params.forEach(param => {
    if (param.active) { 
        queryParams[param.key] = param.value;
    }
});

let rmbfen = queryParams.rmbfen;
let subject = queryParams.subject;
let stringToBeSigned = mchId + orderId + rmbfen + subject + key;
let sign = CryptoJS.MD5(stringToBeSigned).toString().toUpperCase(); 


hopp.request.setParam('mchId', mchId);    
hopp.request.setParam('sign', sign);      
hopp.request.setParam('orderId', orderId); 
hopp.request.setParam('timestamp', timestamp);

My suggestion is to add a button to copy the request link to the picture
or add a new panel.

Or refer to

@21307369 commented on GitHub (Dec 2, 2025): @ozzyrys Some of the parameters of my request scripts, such as the order number timestamp, signature, etc., cannot be displayed here. My script is as follows: ``` javascript import CryptoJS from 'https://esm.sh/crypto-js@4.2.0'; let key = pw.env.get("apikey").toString(); let mchId = pw.env.get("sysid").toString(); const timestamp = Date.now().toString(); const randomNum = Math.floor(Math.random() * 1000000) .toString() .padStart(8, '0'); const orderId = timestamp + randomNum; let queryParams = {}; hopp.request.params.forEach(param => { if (param.active) { queryParams[param.key] = param.value; } }); let rmbfen = queryParams.rmbfen; let subject = queryParams.subject; let stringToBeSigned = mchId + orderId + rmbfen + subject + key; let sign = CryptoJS.MD5(stringToBeSigned).toString().toUpperCase(); hopp.request.setParam('mchId', mchId); hopp.request.setParam('sign', sign); hopp.request.setParam('orderId', orderId); hopp.request.setParam('timestamp', timestamp); ``` My suggestion is to add a button to copy the request link to the picture or add a new panel. <img width="617" height="115" alt="Image" src="https://github.com/user-attachments/assets/7795c637-7c2d-443e-9612-51f2c601169b" /> Or refer to <img width="861" height="411" alt="Image" src="https://github.com/user-attachments/assets/62ebc009-3c44-4666-81b5-75759b327577" />

kerem commented

2026-03-16 17:06:42 +03:00

Author

Owner

@OnlyTL commented on GitHub (Dec 22, 2025):

I think this feature is actually quite necessary.

For users migrating from tools like Postman, the lack of synchronization between query parameters in the URL and the Params table is very unintuitive and can be frustrating. Copy-pasting a full URL with query parameters is a very common workflow, and having to manually re-enter them breaks that flow.

I understand that the current proposed solutions may introduce complexity or edge cases, but instead of completely avoiding this behavior, would it be possible to provide an optional setting / toggle to enable URL ↔ Params synchronization?

This would keep the default behavior simple for existing users, while offering a more familiar experience for those coming from Postman or similar tools.

Even a one-way sync (URL → Params on paste) would already be a big improvement.

@OnlyTL commented on GitHub (Dec 22, 2025): I think this feature is actually quite necessary. For users migrating from tools like Postman, the lack of synchronization between query parameters in the URL and the Params table is very unintuitive and can be frustrating. Copy-pasting a full URL with query parameters is a very common workflow, and having to manually re-enter them breaks that flow. I understand that the current proposed solutions may introduce complexity or edge cases, but instead of completely avoiding this behavior, would it be possible to provide an optional setting / toggle to enable URL ↔ Params synchronization? This would keep the default behavior simple for existing users, while offering a more familiar experience for those coming from Postman or similar tools. Even a one-way sync (URL → Params on paste) would already be a big improvement.

kerem commented

2026-03-16 17:06:47 +03:00

Author

Owner

@liyasthomas commented on GitHub (Dec 22, 2025):

As I've added in https://github.com/hoppscotch/hoppscotch/issues/2227#issuecomment-1851957220, you can send the inline URL parameters list to the Params section by selecting the URL > Add to parameters.

Step 1: Select URL:

Step 2: Click "Add to parameters"

@liyasthomas commented on GitHub (Dec 22, 2025): As I've added in https://github.com/hoppscotch/hoppscotch/issues/2227#issuecomment-1851957220, you can send the inline URL parameters list to the Params section by selecting the URL > Add to parameters. Step 1: Select URL: <img width="1043" height="376" alt="Image" src="https://github.com/user-attachments/assets/f393bf44-b255-4605-89fb-9bf45410a802" /> Step 2: Click "Add to parameters" <img width="1043" height="376" alt="Image" src="https://github.com/user-attachments/assets/d1fd40cd-965d-41b1-a76c-0e503a9b8332" />

kerem commented

2026-03-16 17:06:52 +03:00

Author

Owner

@lenovin commented on GitHub (Jan 21, 2026):

This is a design decision we chose to take. We have seen that for long parameter chains, the effect of the parameters being on the URL is detrimental to the readability of the URL compared to the separated parameters.

We will keep the issue for a while to poll opinions on whether we have to rollback though.

Atleast provide an option for the users to toggle between as a feature than removing the feature completely...

@lenovin commented on GitHub (Jan 21, 2026): > This is a design decision we chose to take. We have seen that for long parameter chains, the effect of the parameters being on the URL is detrimental to the readability of the URL compared to the separated parameters. > > We will keep the issue for a while to poll opinions on whether we have to rollback though. Atleast provide an option for the users to toggle between as a feature than removing the feature completely...

kerem commented

2026-03-16 17:06:57 +03:00

Author

Owner

@Cas-Vandendriessche commented on GitHub (Feb 25, 2026):

I recently switched from Postman to Hoppscotch and I’m definitely missing this feature

@Cas-Vandendriessche commented on GitHub (Feb 25, 2026): I recently switched from Postman to Hoppscotch and I’m definitely missing this feature

Rows
Columns

[GH-ISSUE #2227] [feature]: Syncing query parameters in URL and query parameter input #764

Is there an existing issue for this?

Summary

Why should this be worked on?