Forum Discussion

colomba's avatar
New Contributor
3 years ago

Json response in both raw and json tabs strip trailing zeros

Hello to all,


I am using SoapUI 5.5.0, I am submitting a json request and getting back a json response and I noticed that the trailing zeros in decimal positions are being stripped yet with the same request in Postman the trailing zeros are retained. In testing we want to mimic the response that a service returns and not have it modified. Is there a setting that allows me to indicated that trailing zeros such as 23232.3340 should not be converted to 23232.334 or 1.00 should not be converted to 1?


Need help ...


thank You in advance for you support,


3 Replies

  • richie's avatar
    Community Hero
    Hey colomba,

    I don'r think theres anyway, although someone else might know differently.

    I noticed something similar with mine a couple of.weeks ago, however the RAW displayed differently to JSON tab.

    My example was.when i had a value with 10.decimal places e.g. '99.999999999' and the RAW displayed correctly but the JSON displayed something like '9.E10' (indicating an exponent) whereas the RAW tab displayed correctly.)

    You mention that youre using json. Whats the datatype of these numeric attributes? Json only has 4 primitive datatypes.....string, numeric, boolean and null. So its reasonable for the zeros to be stripped if the values are numeric type, but id expect the zeros to remain if the type was string....? Im guessing the values are strings otherwise id expect postman to strip the zeros as well, but i gotta ask!

    If you were using ReadyAPI you could use an event handler, but you havent got thia option with soapui.

    I can see someone raised this issue with an early readyapi version v1.4 and it was fixed straight away, but that doesnt help you at all.

    Only thing i can thinj of is a groovy script to fix, however i wouldnt know how to do this without the event handler functionality.

    Im sorry i cant be more help. Perhaps one of the other users will be able to sort


    • colomba's avatar
      New Contributor
      Thank You for your response. It is numeric but I don't understand why it strips any response regardless of type. It should return exactly what is returned by service.
      • richie's avatar
        Community Hero
        Hey colomba,

        If its numeric type then normal numeric handling in most tools will remove any zero digits that are the last digits in the sequence.

        E.g. if its numeric then id expect '99.0120' to be presented as '99.012', rather than '99.0120' cos this is standard numeric handling to remove zero digits that dont impact the value.
        When i say "dont impact the value", numerically, '99.0120' is the same numeric value as '99.012'

        However if the value is of string type then '99.0120' is a different value to '99.012' and this is why zero digits are maintained in string types.

        I cant remember whether you mentioned if youre using xml or json. I thunk youre using json, but just in case. Xml instances dont maintain datatypes like json do. That is, if you consider an element in xml, such as:

        <elementName>123.090</elementName>, here you cant tell if the value is actually a string or a numeric. This would be defined in the schema.

        Whereas with json, datatypes are revealed to a point. Due to fact that there are only 4 primitive json datatypes:


        This means you cant always tell the datatype of the content by looking at it.

        "stringAttribute": "123.010"
        "numericAttribute": 123.01
        "booleanAttribute": true
        "nullAttribute": null

        The basic rules for the datatypes are:

        If the value is wrapped in quotes, then its considered a string, even if the value appears to be made up of numbers.
        Boolean attributes can only have either true or false values (no quote marks otherwise, it'd be a string, not boolean)
        Null attributes can only have the value quote marks.

        You might see datetime values and think the datatype is a datetime type like you get in xml, but thats incorrect. The datetime value is wrapped in quotes so its a string!

        I kmow i went on a bit then and i havent fixed your soapui issue but hopefully this bit od background info will help going forward.