Forum Discussion

_onto_'s avatar
_onto_
Helper I
7 months ago

url query string parameters in operator character limit

Hi,

Trying to set up a custom report url using query string parameters with the "in" operator. The documentation states that "URL query strings are limited to 2,000 characters. This limit includes escape codes for special characters (for example, a space, %, +).". From testing though I am hitting a limit at 1679 characters for the full url.  

 

Thanks!

6 Replies

  • Hii _onto_ 

     

    The 2,000-character limit is the theoretical maximum, but in practice Power BI enforces a lower effective limit once URL encoding and internal parsing are applied. Characters used by the report URL itself, the in operator syntax, commas, quotes, and encoded values (for example %20) all count toward the limit, which is why you hit the ceiling around >>1,600–1,700 characters.

    There is no way to increase this limit. To work around it, avoid long IN lists in the URL use a single key or group parameter, pass an ID instead of values, or store the filter values in a table and filter by a reference key rather than embedding all values in the query string.

    • _onto_'s avatar
      _onto_
      Helper I

      rohit1991 thanks for looking at this, the actual 1600-ish character limit I am hitting includes the full url encoded string, with the encoded values included and not just the (url encoded) query string part. 

  • If you’re anywhere near this limit, the URL approach is already fragile. Better options:

     

    1) Use a key instead of a value list
    Pass a single parameter (e.g. GroupId=123) and let the model resolve the list internally via DAX.

     

    2) Use a table-driven filter
    Have a table in the model that represents the allowed set and filter by a single identifier.

    • _onto_'s avatar
      _onto_
      Helper I

      cengizhanarslan without a doubt, this is a fragile approach. But there's also the fact that 1600 <> 2000.

       

      Joke aside, the reason why I considered query string parameters is because of maintenance overhead as I wanted to avoid having to interact with the model if when the requester changes their mind about the values to filter by. What I ended up doing was I set up a parameter in the model which can be easily edited, parsed the parameter to a list of values and used this list in the model. The parameter can easily be edited and only requires a single table refresh so minimal overhead.

       

      Thanks! 

  • Anonymous's avatar
    Anonymous
    Not applicable

    Hi _onto_,

     

    Just checking, have you had a chance to open a support ticket, as suggested. If so, we'd love to hear the current status or any updates from that.

    If the issue was resolved through the support ticket, it would be great if you could share the solution here as well. It could really help other community members find answers more quickly.

     

    Warm regards,
    Prasanna Kumar