When I first started working on Ask-China, I wanted to solve a broad problem: intercity travel is much harder when you do not speak the local language.
China's high-speed rail network is extensive, but the first problem is often not the train. It is choosing the correct station.
A city is not a station
A traveler may know the name of a hotel, landmark, or neighborhood, but a booking service normally asks for a railway station. Large cities such as Beijing and Shanghai have several major stations, and they can be far apart.
That creates a small but expensive decision:
- Which station is convenient from my current location?
- What is its Chinese name?
- Does the station pair have a suitable train on my travel date?
- What should I enter in the official booking service?
I built a free station finder around that gap:
Try the China railway station finder
The flow starts with places travelers already know
Instead of asking users to select a station immediately, the tool asks for two real places: a starting point and a destination.
For example:
- Enter a hotel or landmark in Shanghai.
- Enter a hotel or landmark in Beijing.
- Compare nearby railway-station candidates for both places.
- Select the departure and arrival stations.
- Copy the English and Chinese station names.
- Continue to the official 12306 service to check the actual trains.
The main interface is built in React. Place search runs through a server-side endpoint, while the railway candidates are matched against a controlled station registry. This lets the UI show readable English place information without treating every map result as a valid passenger station.
“Nearest” does not mean “best”
This was the most important product decision.
Distance can help a traveler understand the local journey to a station, but it cannot determine whether that station has the best train for a particular date. A slightly farther station may have a direct service, a better departure time, or more availability.
So the tool presents several candidates instead of silently choosing one. It separates two questions:
- Local access: Which stations are reasonably close to the place?
- Rail suitability: Which station pair has the right train for this date?
Ask-China helps with the first question. Official 12306 remains the source for the second.
Bilingual station names are part of the interface
English names help travelers understand the choice, but Chinese station names are often what they need when using a local app, showing a driver where they are going, or confirming that a ticket uses the intended station.
Each candidate therefore includes both forms, such as:
- Shanghai Hongqiao / 上海虹桥
- Beijing South / 北京南
The selected pair is kept together so it can be copied and checked without translating it again.
Why I did not build another ticket-booking layer
The tool does not sell tickets, collect passport details, display live seat availability, or claim a partnership with China Railway.
Those functions belong to official 12306. The handoff is deliberate: Ask-China translates a traveler's real-world locations into station choices, then 12306 handles trains, dates, fares, availability, ticketing, and railway rules.
On desktop, the website can prepare a station-and-date query for the 12306 website. Mobile apps are less predictable, so the interface also keeps a copy-and-search fallback rather than claiming that every app handoff will be prefilled.
The map is an enhancement, not the answer
I initially treated the map as a central part of the page. In practice, that made the product feel like a rail-network visualization instead of a tool for completing a task.
The current hierarchy is:
- Search two places.
- Compare station candidates.
- Select the bilingual station pair.
- Check the actual journey on 12306.
- Use the local map only when it helps explain station access.
If the optional map cannot load, the station comparison and official handoff should remain understandable. This also forced me to design explicit loading, empty, slow-service, retry, and fallback states.
What I would like feedback on
I would especially value feedback on three questions:
- Is the difference between “nearby station” and “best train” clear enough?
- Does comparing both ends of the trip in one interface reduce confusion?
- On mobile, is copying the bilingual pair before opening 12306 an acceptable fallback?
You can test the current version here:
China High-Speed Rail Map & Nearby Station Finder
If you try it, please tell me the two places you searched and where the flow became unclear. That will be much more useful than a general rating.
Top comments (0)