diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html
index d8e0402f..fd0b4b99 100644
--- a/i2p2www/pages/site/docs/api/samv3.html
+++ b/i2p2www/pages/site/docs/api/samv3.html
@@ -98,7 +98,7 @@ is associated with one of the three types above, and cannot carry
 communications of another type.
 </p>
   
-<h3>SAM connection handshake</h3>
+<h3>SAM Connection Handshake</h3>
 <p>
 No SAM communication can occur until after the client and bridge have
 agreed on a protocol version, which is done by the client sending
@@ -126,7 +126,7 @@ If some error occurred, such as a bad request format, it replies with :
 </pre>
 </p>
 
-<h3>SAM sessions</h3>
+<h3>SAM Sessions</h3>
 <p>
 A SAM session is created by a client opening a socket to the SAM 
 bridge, operating a handshake, and sending a SESSION CREATE message, 
@@ -243,7 +243,7 @@ the session dies for any reason, the SAM bridge closes the socket.
 </p>
 
 
-<h3>SAM virtual streams</h3>
+<h3>SAM Virtual Streams</h3>
 <p>
 Virtual streams are guaranteed to be sent reliably and in order, with
 failure and success notification as soon as it is available.
@@ -257,7 +257,7 @@ he wants to listen to requests coming from other I2P destinations.
 </p>
 
 
-<h3>SAM virtual streams : CONNECT</h3>
+<h3>SAM Virtual Streams : CONNECT</h3>
 <p>
 A client asks for a connection by :
 <ul><li>
@@ -323,7 +323,7 @@ optional human-readable MESSAGE), and the SAM bridge closes the
 socket.
 </p>
 
-<h3>SAM virtual streams : ACCEPT</h3>
+<h3>SAM Virtual Streams : ACCEPT</h3>
 <p>
 A client waits for an incoming connection request by :
 <ul><li>
@@ -382,7 +382,7 @@ passing through the current socket is forwarded from and to the connected
 I2P destination peer, until one of the peer closes the socket.
 </p>
 
-<h3>SAM virtual streams : FORWARD</h3>
+<h3>SAM Virtual Streams : FORWARD</h3>
 <p>
 A client can use a regular socket server and wait for connection requests
 coming from I2P. For that, the client has to :
@@ -392,7 +392,7 @@ open a new socket with the SAM bridge
 pass the same HELLO handshake as above
 </li><li>
 send the forward command :
-</ul><li>
+</ul></li>
 
 <pre>
 -&gt; STREAM FORWARD
@@ -460,7 +460,7 @@ soon as the "forwarding" socket is closed.
 
 
 
-<h3>SAM repliable datagrams : sending a datagram</h3>
+<h3>SAM Repliable Datagrams : Sending a Datagram</h3>
 <p>
 While I2P doesn't inherently contain a FROM address, for ease of use
 an additional layer is provided as repliable datagrams - unordered
@@ -488,7 +488,7 @@ following format :
 <ul><li>
  3.0 is the version of SAM
 </li><li>
- $nickname is the id of the DGRAM session that will be used
+ $nickname is the id of the DATAGRAM session that will be used
 </li><li>
  The target is $destination, which is the base 64 of the <a href="{{ site_url('docs/spec/common-structures') }}#type_Destination">Destination</a>,
    which is 516 or more base 64 characters (387 or more bytes in binary),
@@ -505,7 +505,7 @@ of the message to the specified destination.
 For an alternate method of sending repliable datagrams, see <a href="#dgsend">DATAGRAM SEND</a>.
 </p>
 
-<h3>SAM repliable datagrams : receiving a datagram</h3>
+<h3>SAM Repliable Datagrams : Receiving a Datagram</h3>
 <p>
 Received datagrams are written by SAM on the socket from which the
 datagram session was opened, unless specified otherwise by the CREATE
@@ -532,7 +532,7 @@ or other fields, merely the data that the sender provided.  This
 continues until the session is closed (by the client dropping the
 connection).
 
-<h3>SAM repliable datagrams : forwarding datagrams</h3>
+<h3>SAM Repliable Datagrams : Forwarding Datagrams</h3>
 <p>
 When creating a datagram session, the client can ask SAM to forward
 incoming messages to a specified ip:port. It does so by issuing the
@@ -587,7 +587,7 @@ depending on signature type.
 </p>
 
 
-<h3>SAM anonymous datagrams</h3>
+<h3>SAM Anonymous Datagrams</h3>
 <p>
 Squeezing the most out of I2P's bandwidth, SAM allows clients to send
 and receive anonymous datagrams, leaving authentication and reply 
@@ -648,7 +648,7 @@ as appropriate. Support for the ID parameter may be added in a future release.
 
 
 
-<h3>SAM utility functionality</h3>
+<h3>SAM Utility Commands/h3>
 <p>
 The following message can be used by the client to query the SAM
 bridge for name resolution:
@@ -658,6 +658,7 @@ bridge for name resolution:
         NAME=$name
 </pre>
 
+</p><p>
 which is answered by
 
 <pre>
@@ -726,7 +727,7 @@ which is 884 or more base 64 characters (663 or more bytes in binary),
 depending on signature type.
 The binary format is specified in <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/data/PrivateKeyFile.html">Private Key File</a>.
 
-<h3>RESULT values</h3>
+<h3>RESULT Values</h3>
 <p>
 These are the values that can be carried by the RESULT field, with
 their meaning:
@@ -760,7 +761,7 @@ See those references for option names and defaults.
 Base 64 encoding must use the I2P standard Base 64 alphabet "A-Z, a-z, 0-9, -, ~".
 </p>
 
-<h3>Client library implementations</h3>
+<h3>Client Library Implementations</h3>
 <p>
 Client libraries are available for C, C++, C#, Perl, and Python.
 These are in the apps/sam/ directory in the <a href="{{ get_url('downloads_list') }}">I2P Source Package</a>.