# Numeric Text Field - Float vs Double Issue **URL:** \ **Category:** Ignition\ **Tags:** vision\ **Created:** [November 4, 2026, 2:41pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double-issue/117737 "2026-11-04T14:41:47Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [November 4, 2026, 5:44pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double-issue/117737/6 "2026-11-04T17:44:21Z")
This is a known/accepted issue in Vision's numeric text field component; if you want to talk to support you can reference our internal ticket number IGN-11528. We're delegating the internal string -\> number type to an external library, and that external library goes from smallest -\> largest possible presentation, and `13.3` happens to be a value that can be (acceptably to the library, at least) represented in a 32-bit float, and therefore that's what is returned. Changing that logic in the numeric text field risks regressions in the other direction - there is no winning. We talked about the idea of introducing a "precision" editor component that worked the other way, but deferred it due to relative lack of demand. What you could do today would be to use a _formatted_ text field, with a regex to only allow numeric inputs, and 'bind' the writes back to a tag yourself. --- _[View the full topic](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double-issue/117737)._