Intelligent Unit Orchestration
The Universal Converter was designed to solve the problem of inconsistent measurement inputs in technical documentation and engineering workflows. In many real-world scenarios, users do not provide clean, formatted numbers; they provide text strings like “10kg”, “5 meters”, or “100 lbs”. This tool bridges that gap by using a multi-stage normalization engine to identify units and values from raw strings and convert them into any target system.
Problem Statement & Requirements
Traditional converters often fail because they require strict input formatting. The goal of this project was to build a robust system that handles:
- Natural language inputs: Extracting units from concatenated strings (e.g., “10km”).
- Unit synonyms: Recognizing that “meters”, “m”, and “metres” all refer to the same base unit.
- Scale awareness: Automatically converting between milli, centi, kilo, and other SI prefixes.
- Bidirectional conversion: Moving between Metric and Imperial systems without losing precision.
Identifying values, symbols, and abbreviations automatically.
A search-style experience for 500+ unit variations.
Supported Conversions
The Processing Pipeline
The first and most critical stage is turning a noisy string into a computer-readable object. My normalization algorithm follows a strict 7-step sequence:
- Trimming: Removing leading/trailing whitespace.
- Lowercasing: Standardizing the text to prevent case-sensitive mismatches.
- Separation: Using regex to split numbers from letters (e.g., “10km” becomes “10” and “km”).
- Validation: Checking if the numeric part is a valid float.
- Synonym Mapping: Looking up the unit string in a dictionary to find the base unit (e.g., “kilometers” mapped to “km”).
- Scale Detection: Extracting the prefix (kilo, centi, etc.) and determining the multiplier.
- Object Creation: Returning a standardized JSON object
{ value: 10, unit: "km", base: "meter" }.
This multi-step approach handles the variability of human input, where a user might type “10 KG”, “10kg”, or “10 kilograms” and expect the same result.
Data Orchestration
A large part of my work was in preparing the data behind the tool. Since the project covers many different types of conversions, I had to compile and organise a wide range of metrics, codes, categories, and mappings before the interface could work properly.
I collated units across all conversion areas, grouping them into logical categories so the system could distinguish between measurement units, digital storage, currency codes, crypto symbols, and more.
[ MAPPINGS ]
- • Linking full names to abbreviations (Kilometre → km)
- • Handling structured codes (HEX, RGB, Tickers)
- • Standardizing symbols and short-forms
[ LOGIC ]
- • Formula-driven for metric/digital scaling
- • Lookup-based for clothing and shoe systems
- • Date-logic for relative time requests
Mapping different lexical variations ensures that instead of treating every string as a separate case, they all point back to a single internal standard.
Conversion Categories
Formula-Based
Metric, Volume, and Digital storage use fixed mathematical relationships. The challenge was maintaining a clean, consistent tree of conversion factors across 50+ units.
Design Principles
The architecture was guided by three core engineering principles:
- Decoupling: The UI logic is completely separated from the conversion engine, allowing the engine to be reused in CLI or API environments.
- Immutability: Intermediate calculation steps never modify the original input, ensuring a clear audit trail for debugging.
- Extensibility: New unit types (e.g., digital storage, pressure) can be added by simply updating the unit mapping dictionary without changing the core algorithms.
Final Outcome
The finished tool provides a seamless, unified interface for hundreds of conversion types. It handles history, favorites, and account-based personalization, turning a simple utility into a comprehensive productivity dashboard.
Handling Bad Inputs
I implemented aggressive error handling to prevent the application from crashing. If the engine receives an input it doesn't recognize (like “abc” or “hello m”), it returns a clear, user-friendly error message explaining exactly what part of the input it couldn't process. This feedback loop is essential for maintaining trust in technical tools.
Results & Future Scenarios
The final tool achieved 100% precision for all supported unit systems during testing. While currently limited to basic physical measurements, the logic is ready to be expanded into:
- Dynamic exchange rates: Connecting to an API for real-time currency conversion.
- Timezone math: Handling complex offsets and daylight savings adjustments.
- Compound units: Processing inputs like “10 km per hour” or “5 Newton meters”.