htons()는 부호 없는 16비트 정수를 받아 호스트의 네이티브 바이트 순서에서 네트워크 바이트 순서로 변환한다. htonl()은 같은 변환을 32비트 정수에 대해 수행한다.

호스트의 바이트 순서와 네트워크의 바이트 순서가 같은 플랫폼에선, 이들 함수가 아무런 동작도 하지 않는다. 최적화를 켜면 컴파일러가 이를 인지하여 아예 함수 호출 자체가 없는 것처럼 코드를 전혀 생성하지 않는다. 바이트 순서가 다른 플랫폼에선 주어진 값의 바이트가 뒤집혀서 리턴되는데, 순서가 바뀌었을 뿐 의미하는 값 자체는 똑같다. 이런 플랫폼에서 디버깅하다 보면, 값을 분명히 제대로 넣은 sockaddr_in 구조체의 sa_port 필드 값이 원래 지정한 포트 번호가 아닌 다른 값인 것처럼 보이는데, 이는 바이트 순서가 뒤집힌 채로 디버거가 십진수로 보여주기 때문이지, 틀린 값이 들어 있는 것은 아니니 혼동하지 말자.

패킷을 수신하는 등 몇몇 경우엔, 소켓 라이브러리가 sockaddr_in 구조체 내용을 채워 주는 경우도 있다. 이때 sockaddr_in의 각 필드는 아직 네트워크 바이트 순서로 채워져 있으므로, 이를 읽어서 올바른 값으로 사용하려면 ntohs()와 ntohl()를 호출해 도로 호스트 바이트 순서로 변환해 주어야 한다.

uint16_t ntohs(uint16_t networkshort);
uint32_t ntohl(uint32_t networklong);

이들 함수의 동작 원리는 반대 역할의 htons(), htonl()과 같다.